Iterating on Open Source - JSJ 615

Hey everybody, and welcome to another episode of JavaScript Jabber. This week, on our panel we have Amy Knight, Hey, hey from Nashville. Steve Edwards, Hello from the Left Coast in Portland. Aj O'Neil yo yo yo, come a act you live from the can't make up It's mine about the weather provo that is so true. I'm Charles Maxwood from devchat dot TV. I just want to quickly shout out about my book should be out when this

goes out, The Max Cooder's Guide to Finding your Dream Developer Job. So if you're worried about job mobility or looking for a job, this book kind of lays out how to be attractive to development employers. Sorry, I kind of stumbled over that a little bit. This week we're going to be talking about iterating on open source, and it sounds like Aj and Amy kind of had a conversation about that and wanted to talk about it on the show. So I'll let the two of you jump in and kind of set the stage

and then we can go from there and see where we end up. All right, well, I want to be kicked off with some some questions or props. So Amy, you remember the conversation probably better than I do out. Yeah, I'm trying to think back to what we had chatted about, and I feel like the premise was kind of how the open source project that you work on, that you're you know, trying to make improvements along the

way, but then you get feedback. Sometimes that is a little tough because it, you know, goes against some of the functionality you may have added to the framework, and they're not happy about it. But at the same time, like that feedback, while it's not always you know what you want to hear, it helps you understand how people are using the software. And Okay, okay, so I've got to I've got a good point to start from on this. Okay, So actually, aj you broke it. There's

two things, or probably more. You've got some code that you write and you solve a problem, and most of the time it's a really stupid problem, like left pad for example. And I wrote this little utility called how NPM am I, and it will use npm's API and then printiple list. So if you do NPX how hyphen NPM hyphen am hyphen I, and then your username on NPM dash dash verbos, you'll get this like nice long list

of all the packages. Well, actually it won't include all of them because there's certain metrics that like if you have a collaborator on the package, sometimes it doesn't show up in this list because they did something with their API, where like if it's a scope package or if it's a package that has collaborators, it doesn't necessarily show in your specific list. But anyway, so I've got this list here. My most popular package gets thirty nine million downs ownloads

per month. And guess what it does. That's kind of an unfair question. It's essentially left pad. It's a package called A to B and all it does it's one line long. I think it's a little bit longer than that because it's it tries to like detect in case you're happen to run it in a browser, which would be against the point. But anyway, it's it's basically one line long. It's a return buffer dot from data Comma Base sixty four. That's it, right, So that is a popular project,

but it's not really a useful project. Doesn't really solve problems or help people. It's it's kind of dumb. On the other end of the spectrum, something that I have that only gets about looks like sixty six thousand downloads per month is what I consider to be my most important and you know, best, greatest value contribution to open source, which is it's greenlock and it's an

HTTPS server. And I've talked about this a couple of times, but sorry, it's a let's encrypt client and greenlock Express is also an HTTPS server. So when you're doing open source, like if you get in early, like I got into node in the literally v zero point two days, and so that's how I have a module that gets thirty nine million downloads a month is because I published a one line thing, you know, I don't know, eight years ago and it got included in a bunch of stuff by mistake,

and it, you know, it remains there. But that's like there's nowhere, So my most popular module, there's nowhere for it to go. There's nothing I can do with it. There's there's no additional value that I can help bring to people. It's just kind of like a cool little badge of

honor. Like, look, I made a stupid thing and for some reason people started using it, and I don't know, you know, but when you've got something that actually solves a problem and gives people business value, like this let's encrypt client, and people want as to sale certificates for all their sites. They want to have wildcard sales certificates, they want to have certificates that work locally in development, that sort of thing. So it provides like

real value. They actually save money by using this, and in many cases they're saving thousands of dollars, if not directly in SSL costs by the certificate, they're saving thousands of dollars in the time that it would take them to figure out how to build a system that would work with let's encrypt or even with another paid service. You know, even if the paying of the certificate wasn't the problem, the building the software to negotiate how to get that certificate

and keep it up to date as an automatic process. So it went from something that I built for Hub, which is the homest that I'm slowly slowly working on, to not you know, not entirely by happenstance, Like I wanted to make it easy for other people to use too, because I thought this is not going to just be useful for me, This is going to be useful for lots of people, and this is high value, so I wanted to make it easy for other people to use, and it got to

a point where the popularity of it did not like, you get this burden of responsibility. So let's encrypt was a draft standard. They only just finalized it recently, and so over time I have to make changes to accommodate their API updates, and those changes, you know, they take away from from

my time. And it got to a point where it wasn't just a couple hundred people using this, now it's several thousand people using this, and there's like this social responsibility of oh, well, I want to be a good citizen. I don't want to give people something that they and they rely on and then I don't support and then you know, it brings financial harm or it puts this you know, great technical burden that people didn't expect on them.

But at the same time, like it's an open source project, so it's not like my time for what you know, what I put into this is is being recouped, and I don't necessarily need all the things that other people need. So it's almost like, I, what's the expression, you build yourself into a trap that's not the way when we idealistically think about open

source, that's that's you know, not the language that we use. But when you have a project that begins become popular, that's kind of what happens because you have this you know, feeling about like yay, I'm providing value to people, I'm making a difference, like this feels good, But then it also becomes more demanding on you and you get to a point where you

need to be able to to justify the time spend. And just one thing that I believe about life in general that I'm not, you know, I'm kind of a hypocrite because I don't follow through it in the way that I ought to and according to my beliefs, but I believe that you should capture the value of what you create. When you create value, I think it's it's somewhat of a moral obligation. Maybe morals too strong of a word, but I believe that we have an obligation to capture the value of what we

create so that we can reinvest and then create more value. The kind of Western concept of the more you have, the more you should use to build more abundance, Like you should use abundance to create more abundance. That's in a lot of what people believe in the tech space in general. Paying it forward. Yeah, I wouldn't quite use those terms. I think that that adequately describes it. But it's like, if I have developed it, let's

put it in terms of money. If I've developed a capacity to generate money, you know, I've developed a capacity to generate a thousand dollars. I've got two options. I can take that thousand dollars, find you know, fairly low income housing and eat ramen, and that can be my life. Like I have now come to a point where my life is sustainable. But what would be better is for me to start investing part of that thousand dollars and then find a way so that not only can I help myself, but

I can help others. And that's kind of the principle of capitalism in a sense, Like you can look at capitalism from a negative lens, but if you look at from the positive lens. That's kind of the idea behind capitalism is that once you find a way to elevate yourself so that you are not stuck, you then start looking for ways to elevate other people. You know, you want to get employees, you want to increase your service offering. Da dah dah da da. And the open source is kind of it's kind

of in a weird nomad's lens sometimes because donations really don't work. They work if you have a project that gets billions of downloads per month, but there's you know, how many projects get billions downloads for a month and maybe twenty of them And I mean that's a stupid number. I didn't do any research

to arrive at that, but I know that the number is small. And if you take out things that are like left Pad that you know, might get billions of downloads a month but don't have any business value because you could just you know, write that one line of code on your own and you don't doesn't really save you any time, it doesn't, you know. So if you if you just focus on things that are really valuable, like for example, view JS or React. Well React is backed by Facebook, so

react that what React is is it's it's a tool for marketing. It's it's a way to market Facebook development basically right and view jas is on the opposite side, it's a tool that wasn't created and then released as a as a you know, more of a marketing style effort to draw people in and attract them. Don't think that I'm making some sort of moral call on like you know which way is right or wrong. These are tools, but they came

about in different ways. But the creator of ujs, in order to be able to devote time and attention to it, has to create a way of supporting himself around it. And so he was one of the very few people in the world to be able to successfully use Patreon to actually be able to

account for his own living expenses. And it looks like, I don't know where he lives, but you know, he may be just kind of skating by if he's in the Bay Area, or if he's outside of the Bay Area, then you know he's definitely making enough to cover his own costs and perhaps even hire an employee or something. So as your project grows, it has to change in order to continue. It's this paradox of you're either moving

forwards or backwards. You're never standing still. You're either climbing the ladder or you're falling down the slope. You're never standing still. So as you get a project to a certain point, you have to start to figure out what you're going to do to get support. I ran in an Indiegogo campaign. It was relatively successful. I got about six thousand dollars because there was a little bit that came through a side channel because forever reason people weren't weren't able

to use the Indigogo platform. But what it generated was enough to make me realize, a, this is actually really valuable. It's not just sixty six thousand downloads from somebody's CIICD system that's stuck in a loop, because there's definitely that that happens too. When you look at your download count, there's there's definitely stuff that you're getting that's got getting downloaded once per second just because somebody somewhere put in their CICD system and it's got like a flaw and it's just

running continuously. Right. So what it validated to me is that this is something that people care about. It is something that's important, and it is something that I'm not going to be able to sustain just in my free time, nor do I want to. I don't want this to just be something that sits stagnant. I want this to be something that I can devote effort into and whatnot, And so I have to think about, well, what can I do to bring more value to the table. What can I do

to help more people and to save more people money? Because if I can save somebody a hundred bucks, most people would be pretty happy to pay ten dollars to save one hundred dollars. So as I look forward to, like, you know, what can I do, how could I put in management tools? How could I integrate with a cloud service? Because people are integrating with S three to store their certificates, some of them are you know, trying to figure out how to do encryption on the certificate so it's not sort

of plain text. Blah blah blah. I'm thinking about this and there's a lot to unpack here. I mean, you kind of run through kind of a stream of consciousness with a lot of this, and I'm trying to decide which thread to pick up first, right, because we've got the issue of just maintaining the code right and getting feedback from users, and then we've got

the issue of possibly you know, financial backing and things like that. And we've seen folks like Evan You and Henry Zoo and a few other folks actually get some kind of backing through open Collective or Patreon and make that work. And then you know, we're also talking about yeah, you know, roadmapping

as far as like integrations and things like that. So I don't know where do you all want to start, Amy, Steve aj Do you have one of these areas that you want to kind of pick on first, because I'd kind of like to just work through all of them, but I don't know which one to go at first. Oh, it's good, kind of that's kind of backstory. I did want to go into the process of the actual iteration. Oh, okay, so you want to set that up for us

then yeah. So when you get a project and it's got some popularity and people rely on it, they develop certain expectations about like what they're familiar with, what they're used to. I mean, I set up the story because there needed to be an ideological shift, because I wanted to be able to capture the value of what I create so I can create even greater value. So I you know, when I look at okay, as I'm building out these changes for what's necessary and the API changes, there's so much old stuff.

I mean, if you've maintained a project for a couple of years. You get this old crappy cruft in there, and it becomes really delicate where you can't take code out because if you do, even though it's like maybe crufty code, you know it breaks something for someone. You can get to a point, I mean, especially when it's not well defined. When you've got a project that's a little bit larger I mean large is maybe not the

right word, but the medium size. You don't know everything when you start, so your first version is crappy and your second version might be just as crappy. But you don't know everything when you start. You're figuring it out, and when you try to keep compatibility, you end up in these cases where you had some bad spaghetti code. You cleaned it up, you change the API a little bit, but kept backwards compatibility so you can update the dots and say no, do it this way, but you don't remove the

old way of doing it, so it doesn't break for any boy. You try to, like you know, progressively enhance it, clean it up as you go, and you start to run in these problems where you can't you literally can't fix a bug because you find a bug and you say, oh, well, if I fix this bug, it's going to cause this backwards

compatibility to break, or it's going to cause something else to break. You get things like that, then you get ideological shifts of realizing like, hey, if people want to put this in Docker, if people want to be able to scale this out, you can't have everything imperative in the code.

It needs to be made declarative. There needs to be you know, a YAML file, adjacent file something like that where you know somebody can use a tool manipulate manipulate this fairly simply maybe use a CLI tool with an environment variable or something like that, and then you shift the way you know, the way that config is done or something like that. So as you grow, you have to tease things apart. You have to eventually have a major version

so you can get rid of old crappy code and you get feedback. And the feedback that you get a lot of times it's going to be from the people that loved you the way you were before the most and are most frustrated about the changes that you're making. And sometimes they've got really valid feedback. I mean, all feedback is valid because people's feelings are valid. It's not necessarily feedback you need to act on. But sometimes you get feedback where they

help you to learn what you're not seeing. They help you to see, well, the people that are willing to support this project on the whatever service they primarily have this use case, there's people. They're the people that are making more money, so they're the people that need to scale more. They're

the people that are willing to support you more. But a majority of your user base might be the one off person, you know, the little guy that you started fighting for in the beginning, which is the reason you know, this whole open source project got started, and the way that they use it is different, and you can come into conflict where you have different sets

of priorities. You got, well, here are the people that are actually helping the project live on, and here are the people that are maybe a greater user base that's maybe not as in a good position to be able to help bring value back to you with you know, in their despite their gratitude, they're you know, perhaps not in a place where they can can help

support the project in that way. And you get valuable feedback and it, you know, it shows you both perspectives and you have to make choices in a matter which choice you make, you're going to, you know, cause inconvenience to someone either going to you're going to continue to not support use cases that will not supporting them will hinder the growth of the project and the reach of the project and the ability for it to affect more people more broadly,

or you're going to inconvenience people that are you know, loyal supporters, fans perhaps even did contribute and don't need that new feature or don't like the quote unquote cleaner API, et cetera. And it's tough, like it puts you in a tough position to make choices as you are going through and iterating and making changes. It makes me think about the h I think, what do

they call it? An RSC request for comment for view three where they talked about the new API and the blowback they got from people was just crazy. I know. Eric Hanchett did a YouTube video just saying, Hey, this is what it is. What do you guys think? And he was just surprised at a lot of the blowback he got because oh, you're going to break this, and oh this is a new way to do it, and

why are you doing this? And so on and so forth, and the view people are like, WHOA, We're just asking for comment, that's all we're asking for. You know, we're not saying, yeah, this is we're going to do it, and we're going to deprecate everything in View two.

And I think they've they're trying to walk the fine line between enhancing and making the project better by adding new features, while at the same time not deprecating stuff that's going to blow away everybody who's using View two and wants to

update to V three. You know, I've seen the same thing in the droupil project over the years, where you know, at some point you've got to deprecate old stuff just to you know, get rid of all the craft and make the code somewhat more the code based, smaller and more efficient. But at the same time, you got to want to maintain some backwards compatibility so you don't blow everybody out of the water all at once. It's certainly

a fine line to walk. Yeah, really is. It also reminded me of somebody who's on this panel who has complained about changes to the JavaScript language

in the past. It's interesting because you see so many perspectives, especially with us talking to different people every week, and some people love the changes and some people hate the changes, and so it's you know, it's looking at it and going okay, you know, how does this actually shake down and how many people does it help versus frustrate versus actually cause you know, major

problems in their coding anyway, and things like that. So so on that note, let me let me add something to if that's cool, do it? I mean, I mean there's also the case of like Angular and Angular JS, which you know, things change so drastically that they really had to like support both ways of going about things, because making the change to get out of Angular JS was going to be like such a massive overhaul for people.

Yeah, I think it's interesting what you're pointing out, Amy, and you know my examples along the same lines right where it was a major shift ES five, S six, where I think AJ in some ways is talking about things like that. In other ways is talking about where it's sort of the we might add these features, but most of the old way of doing it will still work. That VIEWJS has taken right. So in my case,

one of the decisions that I struggled to make. One of the reasons that I you know, I've been so against the language breaking changes in JavaScript,

Like I'm not opposed to adding like cool features that we need. I've been more opposed to breaking the syntax of the language such that if a feature is missing, like say a string prototype is missing, you know, maybe ninety percent of your application can run in an old version of Node or you know, And it's a very small shim to add a prototype to the string. I hesitate to the word class, but I'm working a lot and Go and rust now and I don't have classes either. Actually I don't know that

structs. I don't want it anyway. But you know, you do something like a sync a weight, and it's not like, oh, you know, let me bug fix this. Let me make a one line change where I have a compatibility JS and I add the string prototype that now you know has the includes function or the start pad function. You know, it's not like that you use a sink a weight and now all of a sudden it is hard broken for everyone that does not have a recent enough version to support

that. So I actually have a ton of people on Node six And it was kind of like I went back and forth, and I started out trying to you know, not use anything other than simple additions that are non language breaking additions like you know, started using include start pad inpad, that kind of thing where necessary. But I experimented a little bit with asink a weight, and I definitely think a synco weight is something that's more for experts.

I don't know why people try to get novices on it because it has semantics that if you don't use them, like first of you have to mix async a weight and promises, otherwise you're going to have an ugly API. Either way, you're either going to have the tree of death from the promise or

you're going to have the tree of death from try catch. And so if somebody doesn't understand promises, I really think they shouldn't get into a sink of weight until they understand the basics first, because it's it's a syntax change, it it's kind of a big deal. But anyway, because it allowed me to reduce some complexity in the code, I felt like it was appropriate timing.

And because you know, somebody else pointed out that Node six is now no longer supported security wise, like it's it's dead, like they're not doing long term support updates anymore. And so with it falling off the long term support bandwagon, I decided that, you know, i'd use a sink a weight and you know, of course, of course, when you know, one of the first issues I get opened is like, ah, you broke

my like you broke this bad, Like you broke this really bad. Like now I have to upgrade from node six to node eight or ten or twelve or something, and no matter which version I pick, something else in my stack doesn't work. You know, that's frustrating for somebody. But I thought on a whole it would help hopefully get more contribution and support in the future to have I don't know, I'm kind of on the fence about it. Still, it definitely has helped me to consolidate some areas of the code.

I don't know that most people are what I would consider expert enough to know when is the right place for race and kuwait and when's the right place for a promise? So see how well it helps people contribute to the code,

but at least makes it easier to read in some places. I think this is really where these decisions get interesting, right, I Mean, in some cases it's like, well, the majority of my users are going to be on node eight or node ten or node twelve, and so I can kind of count on them having ace and kuwait and then others it's going to be a different story right where it's you know, folks still on node six and so it's going to break it, and you know, moving forward, you

can kind of assume that more and more people are just going to come in and use whatever the current version of node is, even if they stay there for a long time. And so you've got this, you know, when is the right time to move right when is there enough momentum forward or enough people using the current version to where I can get away with making that upgrade or making that move because it kind of future proofs simplifies some things, and

so there's a positive trade off. And then at the same time, it's like, Okay, well, then what do I do for all of the people who are still on node six that I want to support? But at the same time, I'm feeling like this is the right direction to go because this is the direction the language is going in. So and something that you bring up here. So get lab just had some backlash, and I think they totally didn't deserve it, but they also did deserve it, not that

they deserved it and that I'm passing a moral judgment on them. But everything's all about framing and context. And you know, we all want to help our users, we all want to do the right thing. Well, I mean most of us anyway, there's definitely there's definitely some stuff out there that's not morally right. In my opinion, people making choices because they intend to

take advantage rather than to help. But I think in the case of get lab, they were trying to help their customer base, and they message some changes in a way that really struck people wrong. And I've had that same problem myself. But what I'm getting is you need to have analytics to make those choices. You need to have data to say, like, okay, most of my user base is on node eight, most of my user base

is on node twelve. Like, you need to have data in order to be able to make good choices about how to best serve you your user base. And in the case of get lab, they did something that I had done before, they introduced telemetry, and they didn't frame it in a way that people understood that it was to help them. And there's a lot of about privacy concerns, and I don't I don't think privacy is really the issue

as much as it is choice. But you know, there's there's a lot of thud out there about privacy, and so sometimes things that are you know, benign and even helpful get attacked when I don't think they really deserve it. And with Greenlock, you know, what I found is that the people that are using this product, they rely on it. They want to know if something is going to affect their ability to serve their customers or you know,

serve their personal websites or whatever. And so the way that I was able to better serve them without causing a STIR is a clearly label that they submit a maintainer email and that there is a user agent string for the ACME client which is part of the specification of the protocol, and let them know when they use it, they get an email from me that says, hey, you know, you've been added as a as a maintainer for a project.

Using greenlock, You're going to get the following notices critical security fixes, important bug fixes, and breaking API changes. You may also get a one time message in regards to your usage to Greenlock because I I don't I foresee that. I there's there's some things that I want to put in place that aren't in place yet, where I want to be able to reach out to

the people that have already been using it and let them know. I don't want this to be like a subscription thing where they're going to have botombarded with messages from me or anything. But I want to give people the ability to

know about features that are coming down the pipeline. I'll have like a newsletter or something later on, but I just put that one line in there so that you know, people know that I may, I may come to a point where I want to, you know, send out something in regards to the usage of Greenlock, either asking about it or announcing something that's outside of those three bullet points. But it's not an ongoing thing. It's just going to be, you know, so I can get some stuff set up and

let people opt in and not bother them. And that seems to have been received incredibly well. I tried once before, and I feel like I got more pushback on it in the way that I presented it, but in you

know, and having these maintainer emails. It gives me a link to my community to be able to reach out to them for something that's important when I when I need to, because there are security updates that are going to be coming in node perhaps Node fourteen that you know, I'll be able to let people know like, hey, if you upgrade to node fourteen, you're going to get these you know, security benefits that weren't there. If I find a security flaw in my product, I can let people know. And because

this is about SSL, that makes sense. Like it there's no cognitive dissidence about letting people know about you know, security issues. So it's an open line of communication. And then you know, because it has the user agent that lets me know what no version, then I also have information to say, okay, well, when somebody installs this and registers their maintainer email, I now know approximately you know, I get some feel for what no version

people are on. So if I make a change and I need to announce like, hey, this change is being made for this reason, you need to have no ten in order to you know, for this to work, don't upgrade if you don't have NO ten, I feel like that gives me an avenue where I can make a change it's not a breaking API change, but might require a new feature or something, and keep the communication open and you know, continue to serve the audience that's participating and do it in a

way that's transparent and everybody can feel good. Yeah. I like the approach of transparency and it's I mean, it's it's interesting too. I've talked to a number of people in open source and it seems like that's part of the issue that they run into is just the messaging and how how do I keep

people up to date on what's going on and things like that. And I mean it's tough because some people will opt into your email list and some people won't write, and so they're going to be in a position where you're going to change something and then they're going to come looking for you when things don't go the way that they want or when they hear the rumor that there's a

security issue or something like that. And so I love kind of having that default place where it's like, look, this is how I keep people up to date. These are the kinds of updates you're going to get. And yeah, then people can kind of get actively subscribed to a place where they can get that information. I've also seen certain projects do like blogs and then you can sign up for like push notifications on your computer through your browser,

and so you get notifications that way. And I've seen other outreaches through like Slack and things like that where it's like, hey, there's a channel for you know, package updates and stuff that only the maintainers can push to and things like that. And so I've seen a lot of methods like that that keep that line of communication open. And I really love the approach of just you know, having that place where it's like, hey, look, this is where you get help, this is where you get updates, this is

where you get other information. Here's where you get the walkthroughs on how to start up and all that stuff. Yeah, And I mean the biggest, the biggest challenge I'm facing right now with Greenlock is I came out with my initial V three and I got only a lot of feedback on it from existing users, many of them actually were paid supporters on any Go Go. And I know that I want to set this project up for a couple of things. One, I don't want to have sixteen different ways of doing something.

I want it to be customizable. But I don't want it to be like, for this use case, you do it this way. For this use case, you do it this way. I don't want it to be different. Basically, I don't want it to be different packages. I want it to just be one package with one set of documentation that no matter who you are, kind of progressively enhance customization. Like here's how you go from zero

to one. Here's how you go from you don't have an SSL certificate to you do have an SSL certificate, and then you know, below the fold, here's how you go from one to a dozen. Like you might want to turn on these configuration options if you're this size of business, and then how do you go from you know, a dozen to one hundred or thousand. Here are some additional configuration options that you might want to put on and what it means, Like I introduced a CLI because I'm like, Okay,

the configuration can't live in the code anymore. It's not scalable. It doesn't work well for you know, deployment situations with with Docker, it doesn't work well for reproducibility as in, like if I'm a person like some of us are where we work with multiple clients and we want to quickly be able to get them set up with you know, this web app service that's got the SSL baked in. You kind of want to just be able to get cloned the same repo, you know, your starter pack for your you know,

your project template, and then not have to go edit code. You want to just be able to a configuration tool that generates a Jason file, or you know, copy and paste a Jason file and change a couple of things. You don't want to go in and generate the code, like there's what you commit to a repository, and there's what you can figure per client. So that needed to be separated, and in order to make it easy, I thought, okay, some people are not going to like this. Some

people are not going to like that. Where there used to be one file where you go in and you put everything in in the imperative fashion, now there's going to be two files, where one is the code with very little customization, like almost everybody's file, you know, seventy percent of the files are going to be the exact same lines, and then there's going to be

a Jason file. It's going to be your configuration like these are the domains or whatever and so I thought, well, to make this transition easy, I'll add a CLI tool so you can do NPX greenluck in it, and it actually generates the file for you that has like the ten lines in it that you need to get started to go from zero to one, so you don't even have to copy and paste it like you do the NPM install, and then you do NPX green luck at it and boom like there you are.

It generates it for you. If you need to open up and customize something, you can, but most people won't need to, so it's just bom, it's done. And then I'll have, you know, instead of having to edit the config file by hand, you can just run NPX greenlock defaults agreed to terms true and mpx greenlock sites add my example dot com.

And so I thought this was going to be a big hit because not only does it mitigate the problem of the you know, having now an additional Jason file, but it makes it so you can use environment variables and doctor scripts. It makes it so that you can not have to worry about syntax errors or typos in the config file or the code. Like to me, this is just it's all around a better solution that I see as better for everyone and more scaleable, so it helps the people that are only doing one site

more, helps the people that are doing a thousand sites more. This is I mean to me, just thinking, wow, this is great. And initially I shared it with a couple of people and you know, got some pats on the back. Actually the idea came from talking with people about the changes, and you know, got some pats on the backs like wow,

this is great, like thanks, it's awesome. And then you know, I let more people know about it, and I just immediately started getting really negative feedback, like oh my gosh, Like I don't want to have to deal with the CLI. This used to be so simple. All I had was, you know, a JS file and now there's a JS file and a config file and a CLI and da dad, And I'm like, whoa, Like you can edit the config file directly like this, you don't have

to use the CLI. Butt. I was just so surprised, because you know, I felt like I did something that was really good and it made a lot of sense, you know, especially strategically, and you know, also from new people that were coming into the project. It was very validating because I could see new people were using the CLI. It was helping them get up and started quick and fast. They weren't having any problems. They weren't you know, contacting me that you know, they weren't opening issues.

They're just boom. You know, I can see there were some issues that were opened, but you know, I could see that the COLI usage was helping people. But yet the people that were you know, my my biggest fans in some cases really didn't like it. And it was it was hard to like, how do I handle this situation, Like the people that are supporting me, some of them don't, you know, don't like these changes,

and I want to make things easy for them. And eventually I kind of had to resolve to, well, you know, some of this, it's just people don't like it because it's different. It's not that it's more complicated or that it's simpler, it's that it's different. If they had encountered the read me for the first time ever today, they would be probably fairly happy with what it is. But because it's different, and some of them

know, they wouldn't because they're they're staunch, like imperative code. Some people are imperative code people they want imperative code. You're not going to change their mind about that. It's like the who Moved your Cheese book? Yeah, it's true though. People hate change. They just do. And you know, some people will embrace it and some people won't. And yeah, it's it's hard to know, you know what exactly is going to be sort of

the final repercussion for any of that. And the reason I'm making the change, like I haven't gotten around to making videos yet because I didn't get enough funding from the campaign to dedicate as much time as I would have liked, Like I had to go back to doing you know, my normal client work

pretty quickly. But I still intend to release some videos to kind of walk through I mean, particularly the kind of like a migration video, like this is how you used to doing it, this is why it's changed, this is what the benefits are. And if you don't need those benefits, don't use them, you know, because that's one piece of feedback that you know, I get. It was like, well I don't need that feature,

well, don't use it. I mean it's like it's not that simple, but it is that simple, Like you don't have to use the features you don't need like, you know, I kind of would equate it to the anger that a father has when his daughter gets her first boyfriend. Poison evil, don't don't go. You know, you know, the project is growing

up. The project is not as innocent and the young as it once was, and I'm realizing that there's a variety of use cases that need certain features that Yeah, just the project's growing up, guys and gals and others.

Yeah, I don't know if I have anything to add to that. I mean, it's it's definitely interesting and to some degree I see where you're coming from, and to another degree I kind of look at it and go, yeah, but you still need to serve the people who are using your project, so you know, yeah, I mean, I guess you have to weigh I guess the positive feedback with a negative feedback and figure out, you know, what the utility is. And you know, there's also some measure

like which is kind of where you're coming across. If you don't need it, don't use it in the sense of this is where the I feel like

this project has to go. And what's also terrific about open source is that if somebody really does you know, deeply just agree with you about the direction they can fork it, and so you know, as long as you have a software license that allows them to do that, then they can just go ahead and do that, And then you know they can go and they can imperative away at it, and you can continue to see l I at it

and it's where you're at. It's true. And with the last version, the same thing happened, like there was somebody that basically wrote a declarative wrapper around it, you know. So what I did learn though, I mean it's it's I know where the project needs to go in order to continue to be sustainable and serve more people, right, But what I did learn is that there are areas where I could simplify some things, and in a lot of cases it's like, you know, a three line change to the code

or letting a default value get set. So one of the things that I changed was so let's encrypt has a subscriber email. Customers that own domains have the email that they put in the who is as the ad contact, And then there was updates about you know, the project, things that are important that anybody who is active leaves in the project would most likely need to know so before I just used the let's encrypt subscriber email and you know, said

I'm also going to use this email for security notices, et cetera. And that turned out to be bad because there's a lot of people that didn't speak English who used the project, and I got people putting in their customer email that was perhaps the domain owner and not whereas that's not what's intended with let's encrypt. It's intended to basically the company that's the host is the subscriber email.

So anyway, there's some stuff that wasn't quite clear on the documentation and whatnot, and so people were getting onto the security mailing list not understanding that that's what was happening, in large part because I think the language barrier with the you know, the kind of what what I was seeing happening, it looked like it was a lot of Asian email addresses that are coming in, and so I changed it so that it had a maintainer email, a subscriber

email, and a customer email. The customer email isn't used, it's just in the documentation so that people can see that there's something that's different and they need to get more information. Well, it turns out it's fine for me to use the maintainer email as the subscriber email because that's almost always one to one, And the whole reason I separated them out was really just for documentation to help it be more clear. And so I found out, oh,

I can actually simplify this. I don't need to ask them for their email twice, once as the maintainer, once as a subscriber. For the zero to one case, the maintainer is the subscriber. It's for like the more like the you know, thousand case where there might actually be multiple subscribers for some reason like white labeling or you know that type of thing. So that just needs to go further down in the documentation, and it needs out to the screen to say, hey, this email address is being used as a

maintainer email and as a subscriber email. So there's some things like that where I was maybe duplicating the amount of work that need to be done by a small amount. Just making a couple of line changes here and there made the configuration simpler. And so I'm about to publish, I think I might just skip version three point two and go straight to version four because of the feedback I received, and the changes I need to make in the API are just

different enough than I'm thinking. V three might just only live a couple of weeks and we might just go straight to V four for the refinement that needs to be there to help the most people. So I got the reading stuff

done and simplified some of the things. And also one of the most common issues is people are integrating with other services, for example S three and so it's necessary, well not necessary, but if I want to reach the greatest number of people where they have you know, they're starting to integrate with cloud services and stuff. There's all these plugins that are available for it. But I realize this is also an opportunity to help make the project sustainable and serve

people even better. Is to offer a very simple cloud management system where they can manage their domains and they can have you know, like I'm very familiar with cryptography and you know how to use the note APIs to do these sorts of things. So I can actually give them encrypted certificate storage in basically a bucket style system. I can make that kind of a first class module.

I'm hoping to move it in the direction where it always stays true to what it started was, which is for self hosting, but for those people that are using cloud services in a hybrid fashion. Creating a very simple cloud service to integrate with what I see the needs our most gives me an opportunity to provide people with greater level of service and also to be able to support the

project more long term, so that people can have greater convenience. And you know, there's costs associated with when you're not self hosting, there's a cost, and so it becomes a very natural fit to allow the people that want greater convenience to be able to pay for it and continue to support the project that way as well. So we kind of need to start heading toward picks.

One thing that I'm curious about, and this is probably a good way to wrap up, is just is there kind of an overarching message for this or lesson learned or something like that that you know, listeners can apply to

what they're doing. Like most projects never go anywhere, and this is okay, Like we release something because we think it's cool and we don't gain traction, and it's fine, But if you've got something that starts to gain traction, I would say think early on about how you can better serve that community, and remember that these people are mostly grateful and mostly semi willing to support

you. Like there. It's it's a strange thing in open source, but if you want to have a project be sustainable and you are, you are helping people save money and you're creating value, you deserve to have fruits of

your labor. So my hope would be that as people are creating projects that you know you just have in your mind a way to keep true to your open source ideals, to you know that the self hosted movement, that you know, freedom of knowledge movement, but to not be blind to the fact that a lot of these people probably do want to help you continue to help them, but you have to think, you have to talk with them,

you have to think about their perspectives. And the earlier on you can make some of those choices, perhaps the easier it will be to both get your projects supported and make the transition smooth so you're not going from a non scalable, non hybrid CLS products to one that isn't having to mess up an API or you know, upset people that otherwise would have been happy if that's what they encountered earlier on sounds good. All right, well let's go ahead and

do picks. Amy, do you want to start off with the picks? Sure, let's see. Man, I have a lot because I have been really busy and haven't been on lately, but let me think of a good one here. So I learned about this this morning, which is pretty cool, and I posted it in my work slack. I'm not going to take it from there. But if you are a React developer and you use the React of tools, I guess this came out this like late summer fall. I didn't know about it yet, but it's uh, why did this render?

So it can show you if you're like in the deb tools clicking on a component basically like what caused that component to render? So I know for me that's like debugging wise, super helpful. So I will post a link to there's a medium post that explains a bunch of the React of tool stuff, so I'll put a link in that. I guess that's gonna be it for me. Awesome, Steve, do you have some picks for us?

Yeah, I've got one. So I'm not much of a binge watcher usually because I just don't have time to sit down and spend, you know, multiple hours watching something, you know, maybe the Super Bowl or World Series or something like that. But I got sucked into the Jack Ryan series on Amazon Prime Video. I was actually somewhere on a Friday night and our TV wasn't working, but we did have Amazon, so I started proising around and

watching that and I got sucked in, like into a vacuum. I watched like four hours that night, and the next day I managed to watch another four hours at various parts to the day. And I'm watching on my phone and I'm in bed, you know. So I've only gotten through the first eight episodes, which is a complete storyline in the first season. But it was really really good, and I don't have the issue that a lot of people do who watch The Office. I'm trying to imagine Jim as Jack Ryan,

the same actor. But yeah, it's a really really good show, really well written and really sort of sucks you in. Yeah. I watched the first season when it came out, and I enjoyed it as well. A j do you have some picks for us? I've got one, maybe two. So this video I just think is so incredibly I don't know what the words are to use. It's just it's good. This is the type

of humans that we ought to inspire to be. And if we could all be these this type of human I don't think that we would have any issues with well, I mean, we just wouldn't have any issues with inequality or with conflict. And in the way that I mean, it just seems to be on the rise today. There is let me get his name right day, Darryl Davis. Darryl Davis is a black man who attended kkk rallies.

I think he still might I'm not sure, but he basically, over a period of several years befriended the man who became the grand Wizard of the klu Klux Klan, and he would go to the rallies and would talk with people. And this was his way of spreading tolerance, was through opening a channel of communication. Rather than rather than letting fear govern him, and rather than

being passive and letting fear govern others, he opened channels of communication. And so over a period of years, it started out very small, just had like a meeting and a neutral location in a hotel that it progressed to he invited the Grand Wizard over to his house for dinner. And then it progressed to the Grand Wizard invited over him over to his house for dinner. And I mean I should use his name, because saying grand Wizard is you know,

kind of a derogatory term in some ways. But I don't remember the name of the other individual. But in any case, over a period of years, Darryl Davis befriended this man, and just through constant peaceful communication, through tolerance, through really being a loving human that had such a great capacity to love that it could extend even to someone who didn't love him, he

was able to slowly win this man over. And the man as the Grand Wizard, like the top dog, the main dude of the kluekus Klan, walked away from it and gave him his robes as a token of the symbol of deep friendship and appreciation of you helped me get out of this, and I want you to have this as a memento. And it just like it's the kind of thing that can bring you to tears to see someone with such presence, such internal strength, who you know has over you overcome any sense

of negative mentality to be able to just be an incredibly powerful person. So I I just can't stress enough how important I think the message that that Darryl Davis has to share with people is to our current society. It's so important, and I wish everybody could, you know, watch that and take in what he has to say and learn. I mean, I can't. I don't have the personal strength to do what he did. I'm just not as good of a person as he is. But I am inspired to be more

that way by him. That's really good. Yeah, I'm gonna have to go watch it because I find the combinations of people that you would never think would come together coming together, and then what comes from that that that's just always so fascinating cool. Any other picks before I jump in? AJ, I think I'm gonna leave it with that. I think that is such a powerful message that I would like that to stand on its own as what I picked this week. Yep, all right, I'm gonna go ahead and jump

in with a couple of picks. Now. I realize that, hey, this podcast episode will come out either right before Thanksgiving or right around Thanksgiving, and so I want to give everybody ample time to get some of my Christmas related picks, and things have been kind of up and down for me lately, and so I've been anyway, I've been kind of attaching to the things that make me happy. And one of my favorite things year in and year out is Christmas, and so I'm going to pick a couple of my favorite

Christmas movies. Incidentally, I was thinking about these movies and I realized that two of them have the same actor in them. Of course, the recording of the videos is separated by like forty years, but they're great movies. One of them is It's a Wonderful Life, and it's kind of a nostalgic thing for me. It was always one of my dads his favorite movies, and since we lost him in twenty eighteen, you know, it just kind

of has that much more meaning. But I love the movie. I love the message of the movie, and yeah, I just I don't know, I don't know if I can adequately explain why I love it, but it's just such a positive movie. It's a wonderful Life. They've redone it in color, and I can't decide if I like it better in color or not, but anyway, it's yeah, it's got Jimmy Stewart or James Stewart in

it and Donna Reid. And then the other movie that also has Jimmy Stewart in it is Mister Krueger's Christmas. I remember watching that as a kid. Came out in the eighties. I'm not going to spoil anything about it. I'm just gonna let you go watch it because it is amazing. And again, you know, it just kind of personalizes Christmas in a very meaningful way. And you know, it makes you realize that, you know, whether it's how fortunate you are or some of the upper conunities that you have to

make somebody else feel important at Christmas. It's just incredible. So and both of them have James Stewart in them, So I'll just leave it there. I have a bunch more Christmas movies that I'll probably just pick over the next few weeks, as long as they're not a Hallmark movies check they are not. Most of them are actually rather old for lack of a better term. Most of the Christmas movies that I really, really dearly love were made in

the forties, fifties or sixties. So yeah, so I'll probably pick those and then yeah, people can just go check them out because there are some classic Christmas movies that are just amazing. So yeah, anyway, I'll also just quickly shout out and I send an email out today to the mailing list. We are looking for hosts for several of the other shows, and so if you're interested in being a host, just email me check at dev chatout tv and we'll get that lined up see if we can get you on some

of the shows. And yeah, that's all I've got, So let's go ahead and wrap this one up and until next time, Ma's out Audios my idears.