The Changelog: Software Development, Open Source - You can FINALLY use JSHint for evil (Interview)

Episode Date: December 20, 2020

Today we welcome Mike Pennisi into our Maintainer Spotlight. This is a special flavor of The Changelog where we go deep into a maintainer's story. Mike is the maintainer of JSHint which, since its creation in 2011, was encumbered by a license that made it very hard for legally-conscious teams to use the project. The license was the widely-used MIT Expat license, but it included one additional clause: "The Software shall be used for Good, not Evil." Because of this clause, many teams could not use JSHint. Today's episode with Mike covers the full gamut of JSHint's journey and how non-free licensing can poison the well of free software.

There is some sort of implicit contributor's license agreement, even if there isn't a CLA in place, because the project has a license, and you contribute code to the project under that license, and so your contribution is tied to that license. Right, yeah. It's actually made me think a lot about my own contributions in other open source projects,

and a kind of responsibility that I never really considered. Coming up in open source, just thinking like, oh, open source is great. Doesn't matter. Of course, free software is great. Doesn't matter. Of course, just make projects better. And that's that.

When you do that, you're kind of accruing a sort of different kind of responsibility that like people don't talk about as much. And this is, you know, thinking about this and dealing with this has made me kind of more sensitive to that. Bandwidth for Changelog is provided by Fastly. Learn more at Fastly.com. Our feature flags are powered by LaunchDarkly. Check them out at LaunchDarkly.com.

And we're hosted on Linode cloud servers. Get $100 in free credit at Linode.com slash ChangeLog. Our friends at Retool help you to build internal tools remarkably fast. Stop wrestling with UI libraries, stop hacking together data sources, and stop trying to figure out those access controls. Start shipping apps that move your business forward. Learn more and try it out for free today at retool.com slash changelog. Again, retool.com slash changelog. What's up? Welcome back, everyone.

This is the ChangeLog, a podcast featuring the hackers, the leaders, and the innovators in the software world. I'm Adam Stachowiak, Editor-in-Chief here at ChangeLog. Today, we welcome Mike Panisi into our maintainer spotlight. This is a special flavor of the ChangeLog where we go deep into a maintainer's story. And Mike is the maintainer of J.S. Hint, which since its creation in 2011, was encumbered by a license that made it very hard for legally conscious teams to use the project. The license was the widely used MIT expat license, but it included one additional clause. The software should be used for good, not evil.

Because of this clause, many teams could not use JSHint. Today's episode with Mike covers the full gamut of JSHint's journey and how non-free software licensing can poison the well of free software. Alright, we're joined by Mike Panisi, maintainer of JSHint. Mike, thanks for coming on Maintainer Spotlight with us. Thanks for having me. So we're here to hear the saga, the JSHint saga, which has been a long one. And now you can finally use it for evil, which is somewhat ironic, but we're going to find out why.

First, tell the folks about JS Hint's beginnings because I remember JS Lint, I remember JS Hint but probably not everybody does. How did JS Hint come about and why did it become popular? Sure, JS Hint is a fork of a project that's as you mentioned called JS Lint and JS Lint was maintained really as I I think,

the first probably professional-grade JavaScript linter. And it was self-hosted, so it was written in JavaScript. And it was, for a lot of folks, their introduction to even just a linting. Because we're coming back in the early 2000s, people are just writing their first widgets, having basketballs, trail mouse cursors, and stuff like that. And so using linting is kind of a novel concept in this space.

That's the tool they used. The unfortunate part about that project, though, is that it was very opinionated and kind of emphatically so. So when it determined that things not just were invalid syntax, which are objectively incorrect, but also like, kind of dangerous patterns, it would just report them as all the same. And there wasn't really anything you could do with that. So you were sort of at the mercy of the maintainer, when it came to, you know, how you wrote your code. Things that were technically correct, which would not pass, because they were deemed to be, you know, dangerous. So a lot of folks were not so happy with that.

And one of them decided they should make a different project based on it, which those things can be configurable. So you as a, as, as the developer writing the code had a little bit more say in what was acceptable and what was not acceptable. So that was Anton Kovalev and I've probably mispronounced his name, but he, working with, actually inspired by Paul Irish, who's quite prolific in the front-end development scene, decided to fork the project. And so he created JS Hint as kind of a play on the word JS Lint and made all those rules that weren't objectively syntactic errors, made those configurable

so they could be enabled or disabled. Yeah, I do remember that. And I'll say to Anton's credit, I think the name JS Hint was a bit of marketing genius because we're going to talk about adoption and things that lend to open source adoption or non-adoption. And one thing is making your value proposition

very clear from the beginning. And anybody who'd come across JS Lint and had felt really kind of the pain of what is sort of a draconian linter, like an overbearing, like you said, unconfigurable linter, when they heard about JS Hint, it clicks immediately what this is in comparison to JS Lint, right?

Where it's like a fork of that, only instead of it being linting in this heavy-handed way, it's hinting, even though it's still a linter. But just that name for me immediately made it clear like, oh, it's like JS Lint, only I'm going to be able to either configure it or it's going to be less onerous, and I'm going to like using it a lot more. So I thought that was always a clever name for the project. Yeah, for sure. And it's interesting, too, because hinting is not really a term. Even linting is kind, it's kind of a niche bit

of jargon that comes from other software industries. But despite that, you still see it used in Stack Overflow and stuff. People will talk about hinting their code as kind of like a legacy reference, even when they're not talking about JS Hint specifically. So it kind of linked

into the consciousness a little bit. Yeah. It seems like it's pretty kind, too, versus being heavy-handed. It's a psychological aspect to just being a little bit more kind with the way you guide people to do better or to adhere to standards. Right, versus slapping them on the wrist or something. Yeah, it's definitely kind. So how'd you get involved then?

That was Anton created it, and how'd you get involved? Well, it was really coming to bear right when I was getting started in the industry. So I was out of school and started my first real job as a software developer at a small company in Boston called Boku. And we were all using it there, and it was kind of like my first real open source contribution and i can still remember like you know it was the tool that we're using and i felt like it was so neat that this is a tool that's telling other javascript developers what's right and what's wrong and like

i found a bug in that there was like a lot of prestige it felt like just inherent in being a linter because you're kind of authoritative over other developers and so being able to contribute to that was like really exciting so i made my first contribution and kind of authoritative over other developers. And so being able to contribute to that was really exciting. So I made my first contribution and kind of didn't think much of it for many years after that. I started becoming a maintainer just because I was following kind of my co-worker, Rick Waldron's, footsteps.

Yeah, and actually he himself was getting more and more involved preparing the project for ES6 support. So the ES6 is the acronym for the revision of the language that was published in 2015. And so it included a whole lot of new features. And getting a linter, which is at the heart of it a parser, prepared for a new version of language requires a lot of work. And so Rick had been a longtime member of TC39, which is the standards body for JavaScript. And so he had the interest and the skill and the knowledge to help other parsers prepare.

So he was doing that with JSHint, and I was myself following in his footsteps and contributing there too. How far back was that again? How many years ago? This beginning? Or this time frame that you're describing now? How far back was that? That probably would have been late 2013, early 2014. So six years ago. Six, seven years ago. Yeah, and so around the time that you became very involved,

there was this adoption issue which started to manifest. And you've gone on a long, somewhat circuitous, but a path to removing that issue over the years. It's finally become formalized in 2020, which was to change the license. And the license itself, back then, and I'm not sure if this was

your choice or if this was Anton's choice or whomever's choice it was, was basically MIT-esque. It was like MIT expat, which I'm not sure what expat is. I read it, but I didn't follow up. Is it MIT with a couple of extra provisions, maybe? No.

You said MIT expat. You caught me being a bit pedantic. It's because MIT is technically a little bit ambiguous. And so if you listen to the Free Software Foundation or folks like that, they'll make this distinction because it may refer to a number of licenses. But generally, when people say the MIT license, they mean the MIT expat license. Okay, fair enough. So it's what we probably commonly think of MIT, plus a clause.

And that clause was, this software shall be used for good, not evil. We could have said it in conjunction. It would have been epic. We could sing it. Oh, I can't sing, but please do. This software shall be used for good, not evil. Was this the only addition to the MIT?

It was the MIT plus that clause. That's right. You would think that would not ruffle so many feathers, but it does. Yeah. So what did that do to the project? Well, that's probably going to be what we talk about this whole time, is what that did to the project.

Yeah, that's a big part of it. In the immediate sense, well, first of all, as far as provenance goes, that was a vestige of it. In the immediate sense, well, first of all, as far as provenance goes, that was a vestige of the JSLint project. So that is not something that Anton... It wasn't a decision made by you guys, because you were a fork of JSLint, and so it was in JSLint.

Right, and so it was subject to the provisions of the original license. Gotcha. This is a Douglas Crockford kind of thing. He's all about good, not evil. That's his MO. Right, Crockford kind of thing. He's all about good, not evil. That's his MO. Right. Crockford, I think this is the first time we mentioned.

So that's Douglas Crockford. He's pretty prolific in this period. Yes. And also worked on, for instance, the JSON 2 parser, which back in the day you had to use a JavaScript library to parse JSON. And so he worked on the JSON standard and the implementation, the reference implementation. So he also made JSLint.

And so, yeah, he has this license that he applies to a lot of his projects that is, as we're saying, the MIT license with this clause. And in an immediate sense, what that does is it essentially makes what is otherwise like a really clear and succinct legal contract,

which is kind of a thing to be treasured, I'd say, in this world. Sounds like it, yeah. It makes that clear and succinct legal contract into something that's really unenforceable and just generally scary to people that take licensing seriously because the term evil has no real meaning in i think any court anywhere uh so if either either you're the type of person that like disregards the license and just uses stuff because it's the source code's available or you you know are recognized that

you're beholden to a contract and you see in this contract terms that you don't understand so what that means for people that like i said have to either take this seriously because they want to or take it seriously because their legal team forces them to so this says to them like i can't i can't use this project because i don't know what it is that i'm beholden to if i do right it's just moves into a vague. I've heard similar things with people who think they can release their code with no license and just claim that it's public domain

because public domain doesn't have legal holding in certain countries. And so actually, no license is worse than it's less free than a free license or permissive license or whatever license you end up choosing because it's ambiguous and they're not going to adopt it if they care

about licensing. And so I've seen people who start with like, this code is hereby issued into the public domain. I feel like SQLite was like that originally and that's where I heard that, but I could be wrong on the details there. And they end up going back and making it licensed because a bunch of people wrote in saying hey I'd love to use this but public domain, I can't use public domain

it has to have a license and so in this case it goes from a place where if it was merely MIT it's like MIT license has been legally vetted and used and it's kind of like out there that it can just be accepted by people that accept that particular license

inside of their organization. But once it adds that other provision, it's just like, well, no longer that. It's something different. That's just enough to be like, I'm just not going to screw with it. I could, and this could backfire on me. Yeah, right, right.

It's almost to the point where when people say, oh, it's MIT with another clause, you almost want to push back, at least I do after years of thinking about this, to say, don't even start that. If it's MIT with another clause, then it's not MIT. So it's not really useful to talk about it that way. But again, with the pet entry,

you can't help it as a guy that works on a JavaScript parser. So I try to keep that bit of feedback to myself usually. Well, as software developers, we tend to focus in on the little things because they sure do make a difference to a computer, right? And they sure do make a difference. I mean, a legal apparatus is a lot like a computer in its pedantry, right? You have to be specific and you have to be clear. And so it's worth sweating

those particular details, whereas in many contexts of life, you're like, dude, leave me alone with that. I don't care. But you have to actually care. If you care about licensing, that MIT plus that clause changes everything, right? And yeah, the way we learned about this was through issue.

It's funny, this was through issue. It's funny, it was through an issue filed by just a contributor that I'd never met before saying, please remove that clause. It's funny, that was filed on github.com. There's certain parts about how it was filed that are somewhat coincidental. For instance, it was assigned issue number 1234, which is just a nice, not round number. Easy to remember. Yeah.

And it was also filed on my birthday of that year for whatever reason. Oh, my. But at the time, also, it's strange that I was one of those people at that time that didn't really care as much about software licensing because despite having contributed to the project, I wasn't aware of its license. And now, you know, it's been a long time, like it's not, and it's not just because of this, but also because of, you mentioned before the Free Software

Foundation, you know, kind of becoming involved there and just generally thinking much more deeply about open source and free software and the distinction between those two, that all this stuff started becoming more and more important to me personally. It's interesting for me to remember the fact that I wasn't aware of that myself. And so that makes me much more sympathetic, I think, to folks that don't necessarily care as much about licensing when I'm telling this story. How big of a problem do you think this was? So you had people say, please change the license, right?

I think you cite in your essays, which we'll link to in our show notes if people want to read the whole story from Mike's keyboard versus his mouth, you cite in there certain situations like a WordPress situation and a few other ones where it's like, we're not using this because of the license.

Do you think this was a widespread problem or do you think most people don't care and some outliers do? Yeah, I would say it's definitely more towards the latter where most people don't care and some people do. And it's really hard to say for sure. I can say just from the perspective of a maintainer that we lost interest, but there's a lot of reasons that could happen. And it would be easy for me to kind of pass that off as like, oh, it's all because of the license and nothing I did as a maintainer, for instance,

had anything to do with it. And there are certainly things I did as a maintainer where I wasn't as good a maintainer or I made some poor choices, for instance, that affected this. But it's a really complicated, the motivation behind free and open source software is really complex.

So there's market forces to take into play and all this stuff. And it's also kind of a feedback loop. And I get into this a little bit in the blog post, but just reflecting on the fact that whatever the reason that a project stops, starts to become less widely used, for open source projects, their user base

is largely driven by their, I should say, their contributor base is largely driven by their user base. If you lose users, you're losing contributors, and it's kind of a vicious cycle in that sense. So I've focused a lot on the license over the years. But it's important, at least at some point, to acknowledge that there are other reasons why any project, including JS Hint, rises and falls. And so it can't just possibly be that. It's lived out there for a while, though, with this license, though. And so to kind of go back to some things you said in, I think it was your post on why you stuck around, essentially. Yeah. The period is with this clause in there that others, especially corporations and commercial users of open source, would begin to become more educated of licensing and more concerned, I suppose, over differences.

And so I would say maybe the curve of adoption and decline potentially was in line with or parallel with external education towards licensing and scrutinizing and the criteria and whatnot. So that might be more like a large bump at the beginning, less concerned about licenses. Oh, get more educated about licenses. This is ambiguous. This is vague. Start to turn or pull those ones out and use those less or replace them.

So it could be multifaceted really, not just simply the cause, but awareness and education around licensing. Because that's certainly changed a lot in the last eight years. Plus with success and adoption, you're going to have, with increased adoption, you're going to start to attract larger entities, right? Yeah. So like me, as a freelance consultant, I wouldn't think twice about,

especially with tooling, like JS Hint is tooling, like I said, part of my development flow, but I'm not necessarily shipping any of that code down a website pipeline. I wouldn't concern myself so much, especially with the MIT Plus clause. But once you start attracting larger entities that have legal teams and have maybe been through legislation

and gotten once bitten, twice shy, these larger corporations or organizations are much more aware of the legal dangers than individuals are, just generally speaking. Although there's definitely licensed nerds out there, as you've slowly become one by necessity, right? Like you learn these things and hey, I'm kind of of a licensing nerd mostly because of nutty ekbal request for commits and michael rogers and just learning about them it's very fascinating but that's that's a

very small subset but i think once you get into the place where your users are spread abroad and are of differing sizes the bigger users are the ones that are going to say, or the potential bigger users who say, we're not going to use this because they're the ones that care. Yeah, and actually it's kind of perverse in some ways because I say it was perversely encouraging in some ways to know that people were kind of stepping away from JS Hint because on the one hand, day to day I'm fixing bugs, I'm implementing features,

and I'm responding to a dwindling number of bug reports, for instance. So I'm very much invested in seeing the project be successful just because it's something that I'm passionate about and trying to maintain. But at the same time, I'm also knowing that usage is going down because of this reason, so that's kind of demotivating. But I say perversely because at the same time, I recognize that the motivation for that is good overall. Like, I'm actually encouraged by the fact that people are thinking more about licenses.

So as much as I say, well, I want you to use, I want people to, I want my work to be used. I also want people to like, really, I think the more important thing is that people care about licensing. So I've always felt like two ways about it. And that's what, that's actually what's been most driving for me personally to get this work done is I want to be able to someday walk away from this project and in good conscience and be like, I didn't just like dump years of my life into a project that I can't even endorse. Our friends at DigitalOcean launched the app platform. Get apps to market faster now.

Build, deploy, and scale apps quickly using a simple, fully managed solution. They handle everything. The infrastructure, the app runtimes, and dependencies. So all you have to do is push code to production with the click of a button. It's that easy. Learn more. Check it out at do.co slash changelog. Again, do.co slash changelog and get $100 in free credit. so mike you mentioned that the license was a problem around adoption and traction but it wasn't the only problem of course everybody makes mistakes especially when you're a first-time maintainer or you haven't maintained something that's so popular. Even long-time maintainers, you know, people make mistakes and they mismanage and they have bad days. And so we can all help one another

by learning from each other's mistakes. I'm curious if you're willing to share a few things that you thought maybe you could have handled better or reasons why you think JS Hint has started to decline that weren't because of this vague license? Sure, yeah. I can think of two big ones. One would be JSX support. So many of your listeners will recognize JSX, but for those that don't,

it's kind of a derivative of the JavaScript language that was popularized, well, actually developed and popularized by Facebook to support their React framework for making web applications. And so folks increasingly, as that framework became popular, folks were increasingly writing code that wasn't quite JavaScript, but it was JSX. So it was JavaScript with additional rules

that were syntactically invalid from ECMA or the official standpoint. And so they, of course, turned to their linter to continue to tell them about bad patterns in their code, except now their code was in a different language. And so as a maintainer of JS Hint, I was pretty reluctant to support JSX. I had a few reasons for this. One, just to get it out of the way, is that I'm no fan of Facebook, the corporation. And so technology that comes out of that place is, you know, I'm less excited to support on a personal level.

But it's not just, you know, it's, I don't want to, you know, JS Hint isn't my fiefdom. And so it wasn't as though I just said, like, I don't like Facebook, therefore, this project is not going to do it. There was some technical reasons for this as well, which is a little bit of, you could say, baggage in JS Hint around its previous efforts to support non-standard edition still language. JS Hint, actually Anton was a member, you'll remember the original maintainer of JS Hint, was employed by Mozilla for a span of time. And during this time, he was very much engaged and involved

with the folks at Mozilla that were experimenting with the language, most notably Brendan Eich, who actually wrote the language initially. And so people may not remember this, but Firefox, the web browser that was produced by Mozilla, was putting out an experimental version of JavaScript. They were calling it JavaScript 1.6. And so it had additions to the language that preceded that ES6 that we were talking about earlier. And it had some of the same features, but a lot of different features. So it was kind of like a playground for Mozilla. And they were just kind of putting out what they wanted to, just to see what worked and see what it would be like.

And they were doing it in a somewhat, I would say, responsible way. It wasn't just like unleashing it in the internet at large. You had to opt in with a script tag that said language type is JavaScript slash 1.6 or something like that, I believe. But still, that required changes to a parser to support. And Anton, being so involved and so generally helpful and interesting in tooling,

extended JSHint to support a lot of that stuff. In hindsight, we can see that a lot of the stuff that Mozilla was working on didn't really pan out. But JSHint still maintains a feature flag that you can turn on called Moz, and Moz enables JS 1.6 support. So to this day, you can still have array comprehensions in quote-unquote JavaScript if you use JSHint. There's a lot of code paths, it's just legacy that we're supporting. And this is a bit of a tangent now, but bringing it back to JSX,

that was very much in my mind, especially when React was first, you know, in its early stages. I was thinking, do I really want to commit this project to all these code paths? Right, I want to make this mistake again. Right, right.

In retrospect again, we can see that maybe that was a bit nearsighted, but it probably seems that way because we know how popular React and JSX have become. Yeah. At the time, it wasn't probably as clear. It just seemed like, oh, this is a weird HTML inside JavaScript thing. How much do I really want to commit to this? wasn't probably as clear it just seemed like oh this is a weird you know html inside javascript thing do i you know how much do i really want to commit to this those are tough decisions right

especially when again once bitten twice shy like you've gone down that path before and you've seen the results of making what is essentially a bet on something that doesn't come through and now here comes another one and it's a non-standard thing. And it's like, well, how big is this going to get? I don't know if we all saw how big React would get or not. I'm sure we all didn't. But especially when you have a bias against Facebook in the first place, you're like, oh gosh, maybe hoping this thing goes away. But it sure has stuck, hasn't it?

It sure does not, yeah. Yep, yep. I want to be fair to say, it wasn't a decision that you make once and that you're stuck with. Sure. While it's true, at one point we didn't know, even today I could be implementing that.

And at this point, JS Hint is kind of, it's not really relevant, I'll be honest, anymore. So the motivation to do that is very low on my, it's even lower than ever, it's probably lower than it's ever been on my part. But getting back to what we were saying before about the... Mistakes. Well, mistakes, sure, but also even before that,

about the vicious cycle, that I might not have personally decided to implement JSX for reasons that were either personal or motivated by past experience. But also we weren't seeing too much clamoring and too many people stepping up to

help do that as a contribution either. So... Right. There's probably some cusp where all the people in other situations might have been jumping at the chance to implement that in this project. We're also being driven away

and going somewhere else. It's kind of like what could have been. Another one that I should say is that there's a really important feature that we just couldn't support architecturally that a competing project well competing sounds pretty negative but an alternative project we'll say

called ESLint did support not initially but I think from pretty early stages which was this concept of auto-fixing. And so ESLint is another linting project, and it offers this ability for a lot of the problems that it flags to actually change your code for you. And it does that because it's kind of built from the ground up with a sensitivity to things like that.

Well, with a sensitivity for that operation. And so in order to do that with JS Hint, it was not architected that way by any means. So it would be a significant, probably a full rewrite in order to make something that could intelligently change parts of code in the way that another project does. So it's almost like new iterations on old ideas

they have an inherent advantage in that they're not really bound to some of the false assumptions made when the old idea was first implemented. Well you mentioned relevance and ESLint and so the question that arises in many people's minds, and which you do address in the post, I'll be addressing here as well, is here you've got this licensing problem, you've got an adoption problem where it was like skyrocketing, now it's leveling out, and you have maybe some features that are lacking. And here comes another project,

which is an alternative, not necessarily a competitor, but an alternative project that has some technical advantages with regard to autofixing. You could have just hopped on the ESLint bandwagon and said, you know what, JSHint was a tool, it was great, it's still there, we're not going to take it off of NPM, but no longer maintained because of these reasons, and I'm going to start contributing to ESLint starting tomorrow, and just pick that one up and put my efforts there. Why not that?

It's a good question. There's a few reasons. And actually, it's funny you should ask because that was very much on the table. Folks that were working on JSA, well, one person that was on the maintainer team, Mike Sherov, did exactly that. And shortly thereafter, actually,

members of the maintainers actually contacted us and said, would you like to do that? Would you like to join the maintainer over at ESLint? And so I was answering this question a number of years ago, even. My answer at the time was mostly focused on the idea of the strengths of having alternatives and the strengths of friendly competition, we'd say. But also, I guess, for the same reason that we like to see more browsers out there, more interpretations of the specifications.

We see that, I mentioned how Rick Raldwin was involved in TC39, and I didn't say what TC39 was, so my apologies there, but that's the standards body that decides what is JavaScript and what is not JavaScript. and I didn't say what TC39 was so my apologies there but that's the standards body that decides what is JavaScript and what is not JavaScript so it seems to me like the more projects

that are actively interpreting that and implementing that and experimenting with it, the better the ecosystem becomes and the more ideas that come to bear I would say the less the decision making from the language design perspective is informed by any one implementation. So that's kind of like a highfalutin reason to have more than one linter. And I mean, honestly, it is it is one motivation. But you know, I'm not, I also have other other reasons that are kind of more practical, honestly. Another reason,

though, is that, honestly, I was kind of dug in. I mentioned this a little bit a few minutes ago, but just the fact that I had already committed so much to this project, I guess you'd say both committed is a double entendre there. Sure. Nice one. Thank you. Yeah, I guess that's a long way of saying pun intended, but whatever.

Right. It's a fancy way of saying pun intended. In any case, I was already so involved that I would have felt kind of bad to just leave that project in the way it was and to have said like, okay, I'm washing my hands of this and that all the time I'd spent is on something that, like I said, I can't endorse. So I wanted to be able to talk about that JS Hint in a way where I could feel proud, like, okay, yeah, nobody uses this anymore,

but at least it's something that I can say, like, it's free software. And that's, like I said, it's really important to me personally. And I guess finally I felt a little bit of, this is kind of strange because no one asked me for this, but I felt a little bit of some responsibility for all the people that were using JSHint.

The MIT license and the not MIT license, but the one that we had, both make stipulations about the fact that the maintainers have no liability. So in a legal sense, I didn't have any obligation. Right, you weren't obligated. But I still felt like,

especially for those people that didn't know and that may discover later that they were using this software that goes against some people's ethical codes, I felt like, wouldn't it be great if I could deliver something for them eventually? I could make their projects a little bit more free than it was when I started. So I was kind of motivated to switch out their dependency

with a free software dependency, even maybe without them knowing. What's the license on ESLint? I'm almost sure it's MIT. I should know this. I asked the question. I don't. You've been sitting over there, Googling. Well, I was thinking out loud about it, and I was like, well, that's probably the best place to go into it. Yeah, it's mit on unchanged mit and so i suppose everything you just said sort of stands in the shadow though of this seven-year process to relicense right so like

in hindsight maybe back when you made that decision you didn't think that in 2020 which was many years later you'd write a post saying watching the ship sink and then talk about seven years of relicensing and all the work that took into that, which is sort of like, I don't know the details so you could share that, but seems like maybe in retrospect, you could say this, but that it would have been a waste to not have made the decision back then just to move to a licensed version. So the idea that you have, you know, friendly competition and diversity in terms of projects totally makes sense i'm not against that one what's a bit one little bit but the licensing issue was present and the necessity to unwind that

licensing issue was a long road as noted by your seven-year process. Yeah, for sure. And maybe we can get into this more. The work itself, it was over the span of seven years, but I don't want to make myself seem too long-suffering. Or I'm burdened by it. Every day I woke up and worked on this license. A lot of it, to be honest, a lot of it was feet dragging on my part. And I unfortunately don't get into this too much in the blog post

and probably I shouldn't. But a lot of it was uncertainty, just saying, will this work? Is this even legally viable? You never look more silly when you try to do something kind of subversive and you fail. So a lot of of time i'm just

demotivated i'm saying like yeah i i do want to fix this but i don't want to fail and you know it's a lot of self-doubt and questioning and so yeah i'm not working on it every single day for the seven years but it's it's kind of all right it's certainly on my mind for all that time at least it's kind of like the difference between having a seven mile journey and having like maybe a half mile journey, but you don't know which direction to go or you're in a bog and you're like moving very slowly. It wasn't like that amount of work. It wasn't seven years of work, but because of confusion or sometimes you're just like down and out because of the situation, all right, you need to rest or forget about it for a few months

and then you pick it back up again. It drags things out. Did you know when you said, first of all, when was it when you said, we're going to fix this licensing problem once and for all? Was that seven years ago or was that somewhere along the line? Let's see. Seven years is when I started working with JS Hint. Gotcha. More along the line. Let's see. Yeah, seven years actually.

My apologies. Seven years is when I started working with JS Hint. Gotcha. Okay. But the licensing itself was probably more like, I don't know, probably five or so. Okay. Ballpark it. Yeah, either way.

And when you started that, did you think, this is going to take us five years? No, certainly not. There you go. So that helps you make that decision like i'm going to fix this i'm somewhat helping answer adam's statement of like this was a huge process and in retrospect maybe like was it worth all of that well it's like when you start the process you don't know it's what's in there right and so it's not like you're you're not baking that in when you make your decision like if you would have known five years from now you're finally baking that in when you make your decision. Like if you would have known, five years from now, you're finally going to be done with this. You might be like,

I'll join ESLint and call it a day, right? So that's a factor. Yeah. And the reason to dive deeper into that is because people are going to listen to this show and think like, wow, I could be in a similar situation, maybe not a one-to-one,

but they could be thinking, there is a competing project or an alternative project to my project that I'm deeply committed in. You know, double entendre, pun and all. You know, they're into it and they're thinking, should I – and maybe they're having adoption issues or seeing a decline like you saw or whatever it might be. Churn around the maintainership or contributors. And I'm thinking maybe my efforts would be more planted if I went with what seems to be more mainstream or seemed to be getting the adoption.

They might be asking themselves that question and sort of leaning on your history and experience to answer that question for them, or at least give them guidance. Yeah, I think it'll certainly revolve, it certainly needs to take into account, or as I said, they would certainly need to take into account their ethical commitments because I think that's one part of that whole equation

that's really hard to balance. If it is just about, oh, this tool is superior and my tool is not, I picked the wrong horse, okay, I'll change it or not. It gets a little bit harder when you're asking yourself what you feel like you should do, what your obligation is, what seems moral. That's a little bit harder to ignore.

You can be pragmatic on tooling and trends and stuff like that, but if you have a principle, a principle doesn't change based on the amount of effort required to hold it up. That's why it's so useful. You've decided morally, ethically, my principle is X. And so whether it takes me 35 minutes or five more years, I'm going to do Y, then the details of that effort don't really matter. You're like, nope, this is the way I'm going.

Right. I think that's admirable too. I don't want to leave that without saying that's admirable. Totally. I mean, to stick around and do, I mean, because in the post where you, it was dug in. One thing you had mentioned was you were still internalizing the ethics of free software, your involvement in JS Hint, and, you know, just how the two trends were inherently oppositional in terms of like free software and the licensing issue we're dealing with. And you felt regret about the way you were spending your time. But because of your commitment, your principles, you dug in.

That's admirable. Well, thanks. Yeah. And it's hard to, false modesty aside, I should also say that it was a fairly interesting project in itself for, as you say, a licensed nerd, just to be like, what does this even look like? What does this involve? What do I have to do?

So I wasn't just flagellating myself for all this time, but also kind of intellectually satisfying to be like, oh, yeah, I guess I do have to do that, or you do this. It also drags you into technical challenges that I wasn't expecting. I mentioned I was contributing to a Rails project. That's probably the most Ruby code I've written

in my whole life. But just in terms of contributor license agreement, so kind of operationally to get this done, like I was doing other kinds of work. I was maintaining a separate history for the project that was rebased on top of the free license.

And that in itself is a little bit difficult. We use the Git version control system and people who use Git were probably familiar with the cherry pick command. But even more than that, to replay a merge commit is actually really, really difficult because you have to like,

you have to cherry pick both sides of the merge and like all this stuff. And that was just kind of fun because like, you know, I really like using Git and I had to solve that problem. But there are other reasons to keep me going beyond just, you know, my ethical standing. So I'm no saint or anything like that. Well, we draw that, I think, that distinction because a sentence or two later in that same part of what you wrote there, you said, I wanted to move on. So we're sort of empathizing with your internal angst. Like, I wanted to move on. This is your words.

I wanted to move on, but that would mean all the work, all my work had been in service of yet another non-free system. I didn't want the result of my effort to be a project I couldn't endorse, which you said earlier. So there's that empathy there like you wanted to like internally you sort of had this feeling in retrospect because this is written recently right that you wanted to move on but something was keeping you involved yeah the hard part about monitoring incredibly complex architecture means that you're probably monitoring with a dozen different tools. And when something goes wrong, you can waste a ton of time jumping between those various tools just to figure out what happened.

That's painful. Our friends at New Relic want to change that. And they're giving you one user and 100 gigs a month completely free to try out. New Relic is three products in one platform. First, you bring all your data from any source into the telemetry data platform. It's a schema-less time series database, so it runs super fast. It's also fully managed, which means it scales without being a burden on you or your team. And next, you analyze and visualize that data in full stack observability, which gives you everything you need for monitoring

and troubleshooting. You can follow an issue from metrics to events to traces to logs in a few clicks. Then things get even easier with automated detection and incident intelligence. They have applied intelligence, which analyzes your data and systems to make sure those key connections are made for you. If there's an anomaly and make sure the alert goes to the right person and only the right person. And best of all, they have super simple pricing to make it easy. Head to NewRelic.com to get started for free with one user and 100 gigs per month. It's totally free forever. Again, NewRelic.com.

And by our friends at Equinix Metal. Have you ever seen a problem and thought to yourself, I bet I could do that better? Our friends at Equinix agree equinix is the world's digital infrastructure company and they've been connecting empowering the digital world for over 20 years now they just launched a new product called equinix metal it's built from the ground up to empower developers with low latency high performance infrastructure anywhere we'd love for you to try it out and give them your feedback visit metal.equinix.com slash changelog and get $500 in free credit to play with, plus a rad t-shirt.

Again, metal.equinix.com slash changelog and get $500 in free credit. Equinix Metal, build freely. So you began this long process. You weren't sure how long it was going to be or what all it would take. You mentioned a little bit some of the technical difficulties. A lot of it had to do with other people and like, how do you go about making this change? So you can't simply just edit the readme and the license file and just delete a line all that probably would have been nice right

just like why can't we just delete that line and then all of our problems are solved right can't do that i did a few times just cathartically but you know yeah you're right i wouldn't just get revert like you know yeah just make the commit and then feel feel better and then put it back yeah well maybe address that as a licensing person or someone who's gone along this path like why Just make the commit and then feel better and then put it back. Well, maybe address that as a licensing person or someone who's gone along this path. Why can't you just change the license and be done with it? Sure, yeah. It's just because that's really the one stipulation of a license

is that it kind of rides with the code. You have to maintain that along with the code as long as you maintain that code. So when you fork it, it's still the same project, it's still the same code base. So you add your additions, but you're still fundamentally contributing to the same code base and you're still beholden to that same license. So the one person that would be able to change it is the author.

That was originally when we got this request, that's what Anton, who was still the maintainer at that moment, did was contact the author of JSLint and ask, we have people in our project, we've forked it, we've added a lot of stuff, we've had a lot more contributors, would you mind if we change the license? And they declined. So that kind of put the kibosh on that particular route. But one thing that Anton, Anton did a lot of really smart things.

One of the smart things that Anton did, though, was he was careful as he contributed to JSHint and as it grew, to put all new source code files, all new source code, into new files. And that included also the tests. So, you know,

it does get down to a file level, a file based level. The license only governs the original source code file that JSLint was written in. So when you make changes to that file, you're still contributing to it. It's called the JSON license. So you're still contributing to a JSON-licensed file.

But if you add another file and then in Node.js, you require that file, and that file can be under a different license if you want. So Anton was very careful from the start to whenever he grew the project and said, oh, we need a new module for this, we're going to have a new file, that file was licensed with MIT. And the same goes for the tests. So whenever they started writing tests, all the tests were licensed with MIT. And the one oddity about JSLint that was in our benefit here was that it was maintained as a single JavaScript file with no tests.

So that's pretty rare for projects these days. And so we naturally were adding a lot more files and so naturally a lot of the contributions that were coming in were to files that were never licensed with this license in the first place. And all the code that we used to verify the correctness of our code was itself you know didn't need to be re-licensed and could be reused in any context under the terms of the

MIT license so that was another kind of benefit or yeah another benefit so how did you get that all done like where did you decide to take it? You couldn't do the first move? That's right, yeah. So the next break in the case, you would say, is that somebody, this is another case where I've never spoken to this person in real life, so I'm going to butcher their last name,

but Simon Cagey was working with the Eclipse project, which is an editor that your listeners might even use. But they showed up seemingly out of nowhere on that issue that said, please change the license and reported that they had a version of JSLint that was licensed with just the MIT license. The reason they had that was because back in the day, this project called Orion from the Eclipse Foundation was distributed with free software.

And they somehow received permission to distribute that software as MIT. And so we don't have access to the discussion that happened to make that possible, but they were granted a version of JSLint that was MIT licensed. So that was really important because it meant that we could start as though basically all the contributions that had been made to JSLint, we could pretend as though they had been made to an MIT licensed project. So that way the original license was no longer necessarily needed to apply. Sneaky. Or

smart. Sneaky smart. From a technical standpoint, this is the fun thing when I tell my parents or I tell my family or really anyone that is in the software development industry about this is I get to explain a little bit of how Git works.

And so this is right at the point where their eyes start to glaze over. But I try to bring them back in because you think about, as a software developer, you think about the process of just maintaining code and it just being a series of patches. And so explaining to folks that, okay, well, if I take the basis of what I was working on and say this is the non-free version and I have one that's identical except it's free, then as long as I have all the changes as these series of patches I could

just quote unquote you know we know that the term replay but we replay those patches on top of the free software version and so you would say that the result of that is an identical project that is now just free software and so by replaying those changes you've kind of proven the fact that if you would start in this alternate universe where you had been using the free software. And so by replaying those changes, you've kind of proven the fact that if you would start in this alternate universe where you had been using the free software version of JSLint, that you would end up with a free software version of JSHint. Yeah. So you have to go in the history of each, essentially the non-free and the free versions of each and sort of find which commit or at which date or which SHA is applicable to that fork, essentially. Because at some point, that MIT license version

is a representation of, in some history, the non-free. That's right, yeah. So I went back into the history of JSHint, and that naturally involves all the commits made from JSLint. So I was able to, in Git terms, rebase JSHint on top of the free software version of JSLint. And because no one changes the license, there's no risk of conflict.

It's not as though I was resolving conflicts because everybody was changing other parts of the license or anything like that. We learned our lesson. We weren't really accepting patches to the license at any point. I'm going to say something funny here, or at least somewhat funny. So that rebase took five years? It's a very slow process. To discover it's an option, maybe it's taken that long.

So is that how you accomplished this goal then? Was you discovered this free MIT version of JSLint and that's how you accomplished this goal? I wish. That was the first step. The rebase did take a little while. It took longer than you might expect. It took maybe a day or so

just because it was rebasing a history that, this is getting in the weeds a little bit, but it was rebasing a history that, this is getting in the weeds a little bit, but it was rebasing a history that was not really clean. So there's a lot of branches that were merged and all these weird things that happened in the history. So rebasing that is not a straightforward operation. We're using Git. As good as Git is, it's not perfect.

It's not great at doing that particular thing. So that operation, yeah, it took a day or something, but it did not take seven years. The problem after that though and this is where being a licensor and being intellectually curious about this process comes in is that conceptually that rebasing was in some ways

invalidating all the patches that we were replaying because conceptually all the people that had contributed to JSHint in the time since they were contributing knowingly or not to a JSON license project, a non-free project. From a legal standpoint, you would say, hey, I gave you my code, I gave you my time,

and I only did that because I believed, for some reason, in the JSON license. When I'm sitting here rebasing your work, I'm in some way violating a contract or the trust that you would put when you contributed this. You said, one might say in the worst case,

the only reason that I contributed your project is because I believe in good and I want to subvert evil. And because you've just changed my contribution to be in a project that where that clause is no longer viable or that no longer present i should say that you know you violated my trust and you've violated the kind of the contract by which i informally or not contributed so we had solved a big problem by finding this free version of

js lint and rebasing on top of that. But we still had to reckon with the fact that all these people had contributed, knowingly or not, to a project that was licensed under those terms. And so we needed to get their permission as well. It wasn't just about the original author, but also about all the people that had contributed in the meantime.

How many people is that? Something like 120 or so, I think. Which is actually pretty good, I personally think, for a free software project, at least on the scale of JSHint. It wasn't as bad as it might seem, though, for a few reasons. One of which being that a lot of the people were contributing the files that weren't JSON licensed, like we talked about. Not all the files were JSON licensed.

And further, a lot of the contributions were what you would call, if you were that license nerd, you would say non-substantive. And those are not really, you don't really need permission to change those because if people fix a typo in a code comment, they're not changing the behavior of the project and they're actually just reflecting something that's objectively true.

That's not really, you don't necessarily need their permission to change the license because they're not actually, the way they've contributed is not really Substantive. Take out all those, take out the ones that were on the files that don't matter or the ones that weren't substantive, typo fixes, etc. Are we talking like 50 people, somewhere in that range? Just guessing. That's a little bit harder for me to answer, but I can do.

I'm trying to figure out how many people you had to email and track down. That's what I'm trying to get. What's your phone call list? Hey, by the way, I found this free version I want to replay. Can I get your permission? It's like when you have COVID and you have to talk to all the people that you were with last week. You're like, oh, sorry, I got to call you.

Yeah, contact tracing. Yeah, that's what it is. It's like contact tracing for a file. Contributor tracing. You came in contact with this file. You may have this disease. Yeah, yeah. Sometimes the JSON license can feel like a virus.

So I can't say, though. Let's see. I can look at the signatures I received and see what I have. Let's see here. Oh, it's a lot of signatures. Okay, yeah, it's a little bit. Yeah, I would say probably 120 or so. So what was that process like?

Just emailing people? Probably some of them you were still in touch with or they're still contributing, so they're probably easier to get a hold of. But what if there was one person that passed away? Maybe you didn't come across that, but if that was the case, would it be a blocker? Would that just end it?

Yeah, I didn't know what would happen, but that's what I did was I wrote an email and I spammed everyone on the contributors list and a lot of people it wasn't even that it didn't even necessarily need to be that dramatic.

A lot of people they changed their email address. Yeah. There are some people that just configured Git incorrectly and I didn't know what their email address was.

So like some people were just in some ways almost lost to the sands of time. So I was like doing some kind of like iffy kind of background searches on people. Like sleuthing, yeah. Yeah, like trying to find people's identities and stuff

and telling myself that was for a good cause. I wasn't just being- Well-intended creepiness. Yeah, yeah. It was enough, I guess. I don't know, because I did it and I did find most people. And most people were right on board. They said, that's great.

Go for it, for sure. did it and i did find most people and most people were right on board they said that's great go for it you know for sure and this is by the way you know where i got into the whole cla thing the um well cla stands for contributor license agreement and that's when i introduced into the project is a way for people to bequeath their control over contributions they've made and so i introduced that and it's a relatively common practice but not well i wouldn't say that it's it's it's not common but it's done in open source projects so i introduced that and we're asked i was just asking people can you sign this and this was like the kind of paperwork way of getting that done and a lot of people most of the developers i

like talked to got back to me very quickly and were really encouraging. Some of them just didn't want to and they were annoyed, frankly, at me asking. They thought that it was my idea of a good time to be doing this. They'll listen to this podcast and be like, okay, I was wrong. You want to name any names to shame them publicly? No, no, I'm sorry. Actually, they mostly came around because you just have to shame them publicly? No, no, I'm sorry.

Actually, they mostly came around because you just have to be kind of rational and be like, listen, I know where you're coming from. I find it just as annoying as you do. And for the most part, they're like, oh, yeah, okay, I can see you're a person. You're not like a lawyer that finds this entertaining. But the real sticking point, though, was for one person that had contributed a lot. And that's important because there are some people that didn't want to sign, but they hadn't really contributed that much.

But one person had contributed a significant amount, and I could not contact. And I couldn't even find, despite my, I guess I'm proud to say I'm not a very good creepy internet detective. But I couldn't, despite trying to find more information about them, I found very little. I guess I'm proud to say I'm not a very good creepy internet detective, but despite trying to find more information about them, I found very little. I started to question whether they were about their safety. That was kind of tough because you're reconciling this silly side project you're doing with the fact that people have real lives and actual bad things can happen to people out there. It was what you're looking with the fact that, you know, people have real lives and they're, you know, actual bad things can happen to people out there. And it was what you're looking for really important. At the end of the day, though, there wasn't really anything you could do

because I can't find this person. I certainly can't help them. So I had to just kind of say, like, that's, you know, I hope they're well, but there's nothing I can really do for that. So I had to turn my attention back to the task at hand, which was what do I do given that there's a significant contribution that I can't get the permission to relicense. And the answer was to rewrite that from scratch. It's a little bit trickier than that because they didn't write just a file. They wrote patches. So I had to work to revert their patches,

which other people had patched on top of. So in reverting, I had merge conflicts of... I had to strangely resolve conflicts that were intended to break the code. But once I had that, I had a version of JSHint that was kind of devoid of that unlicensed contribution. And what I could then do with that is put it in front of another developer

that had not seen JSHint before and had seen its source code and asked them to re-implement it. I was going to ask, you couldn't just copy what they did because that is plagiarism at that point, right? Right, right. You have to black box re-implementation. It's open source and you have the source.

That's right, yeah. What a weird situation to be in. Yeah. And my hands were kind of tied because as much as I would have liked to rewrite it and I had plenty of ideas

on how to rewrite it from having stared at the source code for many years. Like, you know, you're always as a maintainer thinking, oh, wouldn't it be nicer

if you did it this way or that way? I didn't know, at least at the time, if I could really reasonably claim that what my contribution was was truly distinct because, you know, you would say that my interpretation and my ideas were

in some ways informed. So I had to go look for people that had never worked with the project before and ask them to re-implement it. And the number of people out there that are interested in JavaScript, that are interested in parsers, that care about free software, and that they don't mind contributing to a project that's dwindling in significance, it's a very, very small number. And most of them have already contributed.

So they're disqualified. Oh, why? But I went to meetups, I went to software conferences, I posted on Reddit. I actually contacted, I don't know if you remember this, but I contacted you folks at one point to ask if you had ideas of where I could... You did? Yeah.

No way. Yeah. You pointed me to your Slack channel to look for developers. I was looking for just basically developers that wanted to work on this project. Sounds like something we would say. Yeah. I might not have been specific about what the project was because we talked about before about fearing failure

and not wanting to fall on your face publicly. So I didn't always talk about, you know, it was this project that had wide industry recognition, but you know, I did, you know, try to solicit help from folks.

Here it is right here. Got the email July 10th, 2018. Really? I responded. Howdy. Thanks for getting in touch. Join the community and hang with us in Slack.

There you go. I'd love to talk through this with you. You can hang at GS Party too and talk to other GS web folks. Hope to see you there. There you go. You didn't take our invitation, or did you? I think I might have. I'm sorry, it's tough to say just because I got so much silence.

That's all right. I certainly appreciated even the recommendation there because I was really just looking to expand my network and find folks that would find folks. The folks, they eventually showed up but not through my direct ask. The very first one came through the Free Software Foundation. An intern working there

was the Free Software Foundation in some ways, you know, kind of provided the resources for some of this work to happen. So this intern, Ethan Dorda, spent some of his summer or some of their summer working on rewriting. And so that was the impetus to like really, you know, get me thinking this was actually possible was somebody came up and did this.

And it was great to see that it was, it was great to see it was the Free Software Foundation, which I've said before, I've kind of aligned with ethically. So it was neat to be able to work with them. That's cool. There's a lot of work that went into this. Yeah, I know. I mean, I had to chase down people, get signatures. Now I'm realizing why it took so long.

Yeah, I mean, just the cycles and the mental cycles alone, let alone the actual time cycles. And it brings up the, I guess, explicit versus implicit contributor license agreement. So you explicitly asked them to sign one that changed their commits and the license that went with it, right? But you mentioned earlier your obligation and license-wise, there was no obligation from you as a maintainer to the open source. But there is some sort of, I suppose, implicit contributor license agreement that you contribute code to this project, even though there is no CLA and you didn't sign it, that you're contributing to that license. And so you've got a bunch of people who are like,

why are you reaching out to me, Mike? Come on, dude. Are you being serious or whatever? But there's an implicit license agreement there because there isn't one. And there is a license to the project. Right, yeah. It's actually made me think a lot about my own contributions in other open source projects

and a kind of responsibility that I never really considered. Coming up in open source, just thinking like, oh, open source is great. Doesn't matter, of course. Free software is great. Doesn't matter, of course. Just make projects better, and that's that.

When you do that, you're kind of accruing a sort of different kind of responsibility that people don't talk about as much. And thinking about this and dealing with this has made me kind of more sensitive to that. And there are interesting things happening in this case, because in the case of when I pass away, and if that should happen and someone wants to change

the license of a code base that I contributed to, what happens then? There's some legal standing for people, especially prolific developers, bequeathing their rights as part of an inheritance. Part of their will or something. Yeah, exactly. But it's kind of fraught

because actually that can be found to have monetary value. And you can end up like by doing that, you can end up like actually making trouble for the person you're, you're giving those rights to. So really, really good work is done just in general, but specifically on this topic by the software freedom conservancy. And so you can so they have a podcast of their own called Free As In Freedom that you can listen to and kind of get into the weeds about these kinds of issues

and what real lawyers are doing and thinking about these things. And they work a lot with the Debian project, which is a huge and really just massive free software project. It's a whole operating system. They work a lot with contributors there and offer them services.

So they have a lot to say about this. Yeah, we have done a conversation with Karen Sandler from there. Oh, great. Years back. Three years back at least. 238 at OSCON. So I met Karen and had a great conversation with her.

It's on the changelog, but yeah, they're doing great work. And you know, the kind of work that the rest of us, like you said, don't even usually think about these concerns until they like stare at us in the face for some reason. And I would say that I have definitely contributed open source in a somewhat, we'll just call it willy nilly fashion. like, hey, it's easy, pull requests, merge my bug fix, whatever. And I don't think about the implications of that necessarily because it is such a lightweight transaction now. And so even just hearing your story

makes me think about my contributions, right? And maybe the responsibility there that I don't always think about when I'm participating in a project. How often do you open up a new repo that maybe you're using as a dependency and you're going to submit a bug fix and you think, what's the licensing situation of this software? I don't usually think about it myself, but I probably should.

What exactly am I agreeing to here? What if the license said, you will only use this project for evil? I would have a problem with that. But if I don't read the license... I think this is a good cautionary tale for all of us. Maintainers and contributors.

You went through all this work. You had 100 plus people agree. You finally got it out of the weight of the MIT Plus or the JSON license. It's now MIT licensed, August 2020. The blog post's out. It's free. It's officially free software now, or open source software.

And anybody can use it. I guess congratulations on going through and getting to the other side. Sometimes you wonder if you're going to make it to the other side. Well, you made it, so that's cool. What now and what next? Well, thank you. Now I'm not so sure. I think now I kind of just want to round out

some of my contributions and kind of finish up some of the work that I've been most recently working on just because I'm kind of a completionist. They've been introducing new features into the JavaScript language at a much more regular rate the past few years. So I'd like to get some of those last features in. But for the most part, like we've been saying, the project itself isn't really that widely used anymore.

So I don't think many people will be too distraught if it kind of goes away. But I am glad to know that there's a lot of projects out there that rely on it, that depend on it on a technical level, I should say. And what I'm glad to know about those projects is that when we released the software, the free software version, that they got this kind of for free. The way that NPM, which is Node's package manager, the way that it delivers dependencies in a large part is with semantic versioning.

And a lot of people that depend on these packages express their dependencies in ways that can be satisfied by new releases. So there are things that change this, like the way you write your version specifier and whether you use a package lock file and all these things. But for a lot of the people that have been relying on this for many years, those features weren't necessarily available to them,

they got this code the moment we released it because their automated systems, their CI systems, their deployment systems, all these things just pulled from NPM automatically. So that was kind of a benefit. That was kind of satisfying. Even if new people stopped using GSM today, I was able to say, free software is a little bit more widely proliferated now that we've released this. We didn't release a major version.

And actually, that was a whole topic we haven't really gotten into that you can read about in the blog post, which is why this isn't a major version. And yeah, the nerdery that goes into that decision. But next steps for me is probably just to, yeah, probably round out these features and then find a new passion, really. Now we're at that point that Adam was asking about before,

which is in a more pragmatic scenario of saying, where do you want to be spending your time? The ethical component is lifted, and now I'm able to say... You resolve that. Yeah, and so now I'm able to ask that question again and say, well now, yeah, there's not much keeping me here. I don't really necessarily think that I can make JS Hint something that's, well now, there's not much keeping me here. I don't really necessarily think that I can make JS Hint

something that's, once again, that has the power of ESLint. And I should say, I introduced ESLint on a sour note by calling it a competitor, but I should say, really and truly, it's a really impressive software project and I've never felt otherwise.

And also it's maintained by Nicholas Zakas, who you've had on your show a number of times and who I have a lot of respect for. And finally, speaking of maintainership, it's maintained in a really impressive way. They have a whole RFC process and they're taking a lot of new ideas and how you can distribute decision-making

in a way that I think is really viable. So really, this is all just to say it would be really hard for a one-man rinky-dink project to offer the same strength. So I'll be satisfied to leave it in their hands. Is there no other maintainers now then? Your sole maintainer? There are. And yeah, actually, so I guess you would have to really ask them.

I think, though, at this point, that would be Rick Waldron and Caitlin Potter. I think at this point they are mostly there to humor me. So in some ways they may be relieved when they no longer have patches to review, which they do without fail. They'll be related to be done with that. There you go. Here's a question for you then. The next time you fire up a new JS project,

are you using JS Hint or ES Lint? All these years I've always dogfooded. But when I'm no longer maintaining it and I no longer see commits going to it, I guess I'll be using ESLint Well this has been a journey for you for sure and one thank you for being a listener, two thank you for writing in

and so thankful I didn't have a terrible response to you at least I'm okay with what I responded with, really wish we saw you in Slack but I think what we have also changed in our process is, I suppose, thanks to Zoom, it would be easy meeting people where it became really easy to use calendar links and saying, hey, you want to talk or whatever? Link up or whatever. So I wish I would have responded to you and saying,

let's actually talk because that's, I think, the invitation that we try to do with this show. Maintainer Spotlight has been this fun flavor of the channel we've done to sort of dig deep into sort of where RFC left off you know we can't replace Nadia Michael nor will we try but to carry on what happened with request for commits that podcast which was amazing you know we continue with maintainer spotlight uh here on the main show, The Change Log. We want that invitation to be to all maintainers out there. If you're struggling,

we may not be able to help everybody, but we're definitely a community to listen. This is a place you can call home. Hopefully, we can give a slightly better response than that one. I wish I'd have given a slightly better response to you on that one. To give you more of an invitation in, I suppose, than just simply going to Slack, which seemed kind of cold to me.

But at least you didn't ghost them. That's right. At least I did respond. Yeah, yeah. Don't set yourself short. I think that was a really good response, really. I mean, it's good to have ideas for how to improve it, but yeah, that was great. Yeah. Well, I think it comes back to what you said earlier which is there's people there's real people with real lives out there behind software

and that's what i think jared and i really care about most you know sure progress and tech it's fun that's why we're here that's what attracts us but we're here really for the people and i want that to be the message that resounds whenever we show up and do this podcast, or we ship an episode, or we sit and talk with someone like you, or respond to your email. I want that to be what's taken away, that we're here for the humans, not the code. And I think that's what I want to send home for you, too,

but more so to say thanks for the ethics behind you, and being a completionist, and sticking it through and delivering. I think you can move on to your next big thing with a happier heart. And thank you for sharing that story with us. Yeah, really enjoyed it. Yeah, well, thank you. That's it for this episode of The Change Law. Thanks for tuning in. If you haven't heard,

we launched Change Law Plus Plus. If you love our content, take it to the next level by showing your support. We want to take you closer to the metal with no ads. Learn more and join at changelog.com slash plus plus. Of course, huge thanks to our partners who get it, Fastly, Linode, and Lunch Darkly. Also, thanks to Breakmaster Cylinder for making all those awesome beats for us. Thanks again for tuning in. That's it for this week. We'll see you next week. Thank you. We should coin that, Jer. We're here for the humans, not the code.

As I said, I liked it. You just coined it. I totally know what you're saying, and it's funny because I think we could have jumped off of what you said at the end there and just gone in another hour if you two weren't already done with me. But I do want to say just i just want to respond to that a little bit which is you know it it's got to be tough like i have a lot of i have a lot of empathy for you because you're dealing with people all the time and that's what it comes down to i

think like it just must feel like that that you're you know this is another email i have to deal with you know it's like i have i only have sympathy for being in that position. And just to maintain the kind of, I guess, empathy that you want to have is really hard. And you have the psychology podcast, which I don't listen to as much as I should. But I'm sure they've talked about how our tendency is just to be complacent. It's always a fight. Yeah. Remove the relation. Well, that's what I'm so, I suppose like I can grok my own email and I can tell that's a bit robotic because I didn't want to acknowledge at all the challenge that you're facing. I just said, thanks for getting in touch. So there was like zero real

response to what you'd actually said. So I can tell like in retrospect that this was a pretty robotic response for me, even though it seems like it's not that's why you didn't feel so great about it yeah that's why i personally i can tell what i wrote right normally up short we're far more relational and i and it bums me out when we're so busy or it was also i guess the response was also 11 45 p.m so it might have been like a nighttime email who the heck knows what's happening July 10th, 2018. And that's the thing. It's easy to look at that email and be like, oh, I feel bad about that.

But what was hard is to say what else was going on in my life at that moment. And that's something I think a reasonable and mature person like myself assume when you get a response like that. Just like people are people. Well, it's tough because in your situation is one where we probably could have helped move the needle. There's lots of situations where people are just asking us for things and whether they're recruiters or PR people. A lot of the email, we get a lot of low quality emails.

We read all our emails. So it's hard sometimes because we're used to dealing with the person who's just trying to take from us versus somebody who has a legitimate situation in our community and we could probably help them. And sometimes you can't even discern that because you just read your email fast, especially at 11.45 at night.

Well, I just desire to, I suppose, show up better. Yeah, yeah, well, we all let ourselves down all the time. I thought this was actually, ironically, I think that was probably the best moment in the show. It was just hilarious because we were so clueless about it. You're showing all these lengths you went to and you're like, I even contacted you guys and we're just like, what?

Yeah, sorry. I didn't really... It was great. Okay, good. I really didn't consider it. I loved it. No, I loved it. Me too. I thought that was just funny. It's just like out of nowhere. Because when we speak with people, a lot of times we either know you from past interactions

or we assume you don't know who we are and we barely know who you are. That's why I ask, have you ever listened to the show? Because a lot of people are like, no, I'm just here. And so we don't assume past relationships if we don't explicitly remember them. And so this is just a funny situation where you had tried and we didn't ghost you.

The best part is you got in touch and that's sometimes the hard part. Yep.