**To receive your 40% OFF coupon for Manning Publications (good for all our products in all formats) visit us on Facebook - click on "Send A Message"and type "YES"**

Hey folks, I'm a super busy guy and you probably are too. You probably have a lot going on with kids going back to school, maybe some new projects at work. You've got open source stuff you're doing or a blog or a podcast or who knows what else, right? But you've got stuff going on and if you've got a lot of stuff going on, it's really hard to do the things that you need to do in order to stay healthy. And one of those things, at least for me, is eating healthy. So when I'm in the middle of a project or I just got off a call with a client or something like that, a lot of times I'm running downstairs, seeing what I can find that's easy to make in a minute or two, and then running back upstairs. And so sometimes that turns out to be popcorn or crackers or something little. Or if not that, then something that at least isn't all that healthy for me to eat. Uh, the other issue I have is that I've been eating keto for my diabetes and it really makes a major difference for me as far as my ability to feel good if I'm eating well versus eating stuff that I shouldn't eat. And so I was looking around to try and find something that would work out for me and I found these Factor meals. Now Factor is great because A, they're healthy. They actually had a keto line that I could get for my stuff and that made a major difference for me because all I had to do was pick it up, put it in the microwave for a couple of minutes and it was done. They're fresh and never frozen. They do send it to you in a cold pack. It's awesome. They also have a gourmet plus option that's cooked by chefs and it's got all the good stuff like broccolini, truffle butter, asparagus, so good. And, uh, you know, you can get lunch, you can get dinner. Uh, they have options that are high calorie, low calorie, um, protein plus meals with 30 grams or more of protein. Anyway, they've got all kinds of options. So you can round that out, you can get snacks like apple cinnamon pancakes or butter and cheddar egg bites, potato bacon and egg, breakfast skillet. You know, obviously if I'm eating keto, I don't do all of that stuff. They have smoothies, they have shakes, they have juices. Anyway, they've got all kinds of stuff and it is all healthy and like I said, it's never frozen. So anyway, I ate them, I loved them, tasted great. And like I said, you can get them cooked. It says two minutes on the package. I found that it took it about three minutes for mine to cook, but three minutes is fast and easy and then I can get back to writing code. So if you want to go check out Factor, go check it out at factormeals. Head to factormeals.com slash JSJabber50 and use the code JSJabber50 to get 50% off. That's code JSJabber50 at factormeals.com slash JSJabber50 to get 50% off.

Hey folks, I'm a super busy guy and you probably are too. You probably have a lot going on with kids going back to school, maybe some new projects at work. You've got open source stuff you're doing or a blog or a podcast or who knows what else, right? But you've got stuff going on and if you've got a lot of stuff going on, it's really hard to do the things that you need to do in order to stay healthy. And one of those things, at least for me, is eating healthy. So when I'm in the middle of a project, or I just got off a call with a client or something like that. A lot of times I'm running downstairs, seeing what I can find that's easy to make in a minute or two, and then running back upstairs. And so sometimes that turns out to be popcorn or crackers or something little, or if not that, then something that at least isn't all that healthy for me to eat. Uh, the other issue I have is that I've been eating keto for my diabetes and it really makes a major difference for me as far as my ability to feel good if I'm eating well versus eating stuff that I shouldn't eat. And so, um, I was looking around to try and find something that would work out for me and I found these factor meals. Now factor is great because a, they're healthy. They actually had a keto, uh, line that I could get for my stuff. And that made a major difference for me because all I had to do is pick it up, put it in the microwave for a couple of minutes and it was done. Um, they're fresh and never frozen. They do send it to you in a cold pack, it's awesome. They also have a gourmet plus option that's cooked by chefs and it's got all the good stuff like broccolini, truffle butter, asparagus, so good. And you can get lunch, you can get dinner. They have options that are high calorie, low calorie, protein plus meals with 30 grams or more protein. Anyway, they've got all kinds of options. So you can round that out, you can get snacks like apple cinnamon pancakes or butter and cheddar egg bites, potato bacon and egg, breakfast skillet, you know obviously if I'm eating keto I don't do all of that stuff. They have smoothies, they have shakes, they have juices, anyway they've got all kinds of stuff and it is all healthy and like I said it's never frozen. So anyway I ate them, I loved them, tasted great and like I said you can get them cooked. It says two minutes on the package. I found that it took it about three minutes for mine to cook, but three minutes is fast and easy and then I can get back to writing code. So if you want to go check out Factor, go check it out at factormeals, head to factormeals.com slash JSJabber50 and use the code JSJabber50 to get 50% off. That's code JSJabber50 at factormeals.com slash JSJabber50 to get 50% off.

 

CHARLES MAX_WOOD: Hey everybody and welcome to another episode of JavaScript Jabber. This week on our panel, we have Amy Knight. 

AIMEE_KNIGHT: Hey, hey from Nashville. 

CHARLES MAX_WOOD: Steve Edwards. 

STEVE_EDWARDS: Hello from the left coast in Portland. 

CHARLES MAX_WOOD: AJ O'Neill. 

AJ_O’NEAL: Yo, yo, yo. Coming at you live from the camp makeup. It's not about the weather Provo. 

CHARLES MAX_WOOD: That is so true. I'm Charles Maxwood from devchat.tv. I just want to quickly shout out about my book should be out when this goes out, the Max Coder'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 gonna 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.

AJ_O’NEAL: All right. Well, I, I want to be kicked off with some, some questions or props. So Amy, you remember the conversation probably better than I do. Help her build it up. 

AIMEE_KNIGHT: 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 that sort of thing.

AJ_O’NEAL: Okay. Okay. So I've got a good point to start from on this. 

AIMEE_KNIGHT: Okay. 

AJ_O’NEAL: So actually- 

CHARLES MAX_WOOD: Not AJ. You broke it. 

AJ_O’NEAL: 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 npmmi. And it will use npm's API and then print out a list. So if you do npx

how-npm-am-i, and then your username on npm, dash dash verbose, you'll get this nice long list of all the packages. Well, actually, we'll include all of them because there's certain metrics. 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 scoped 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 39 million downloads 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 tries to detect in case you happen to run it in a browser, which would be against the point. But anyway, it's basically one line long. It's return buffer.from data, base64. That's it. So that is a popular project, but it's not really a useful project. It 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 66,000 downloads per month is what I consider to be my most important and best, greatest value contribution to open source, which is it's green lock and it's a HTTPS server. And I've talked about this a couple of times. Well, it's 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 0.2 days. And so that's how I have a module that gets 39 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 SSL certificates for all their sites. They want to have wildcard SSL certificates. They want to have certificates that work locally and development, that sort of thing. So it provides 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, the home server that I'm slowly, slowly working on to not entirely by happenstance. Like I wanted to make it easy for other people to use too, because I thought this is not gonna just be useful for me, this is gonna 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 the social responsibility of, Oh, well, I want to be a good citizen. I don't want to give people something that then they rely on and then I don't support and then, you know, it brings financial harm or 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 build yourself into a trap. That's not the way when we idealistically think about open source, that's not the language that we use, but when you have a project that begins to become popular, that's kind of what happens, because you have this feeling about like, yeah, 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 spent. 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 with 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 somewhat of a moral obligation. Maybe moral is 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 a lot of what people believe in the tech space in general. 

AIMEE_KNIGHT: Like paying it forward. 

AJ_O’NEAL: 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. I've developed a capacity to generate $1,000. I've got two options. I can take that $1,000, find fairly low income housing and eat ramen, and that can be my life. 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 $1,000 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 it 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're 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 da da da da. And the open source is kind of, it's kind of in a weird no man's land 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 of downloads per month? Maybe 20 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. So if you just focus on things that are really valuable, like for example, Vue.js or React, well, React is backed by Facebook. So what React is, is it's a tool for marketing. It's a way to market Facebook development, basically. And Vue.js is on the opposite side. It's a tool that wasn't created and then released as a 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 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 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, 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 an Indiegogo campaign. It was relatively successful. I got about $6,000 because there was a little bit that came through a side channel because for whatever reason people weren't able to use the Indiegogo platform. But what it generated was enough to make me realize, A, this is actually really valuable. It's not just 66,000 downloads from somebody's CI CD system that's stuck in a loop. Because there's definitely that happens too. When you look at your download count, there's definitely stuff that you're getting that's getting downloaded once per second, just because somebody somewhere put in their CID, 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 gonna 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 $10 to save $100. 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 S3 to store their certificates. Some of them are trying to figure out how to do encryption on the certificate so it's not sort of plain text, blah, blah, blah. 

CHARLES MAX_WOOD: 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 at 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 Yu and Henry Zhu 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, road mapping 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? Cause I'd kind of like to just work through all of them, but I don't know which one to go at first. 

AJ_O’NEAL: I was going to kind of do that. That's kind of backstory. I did want to go into the process of the actual iteration. 

CHARLES MAX_WOOD: Oh, okay. So you want to set that up for us then? 

AJ_O’NEAL: 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 you know, 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 in 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, and 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 docs and say, no, do it this way, but you don't remove the old way of doing it. So it doesn't break for anybody. You just 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, a JSON 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, 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 rev 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, you know, 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, the little guy that you started fighting for in the beginning, which is the reason 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 and no matter which choice you make you're going to you know cause inconvenience to someone you're 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 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. 

STEVE_EDWARDS: That makes me think about the, uh, I think what did they call it? An RSC request for comment preview three, where they talked about the new API and the blowback they got from people was just crazy. Oh, 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 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 v3. You know, I've seen this same thing in the Drupal 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 cruft and make the code somewhat more, uh, the code base smaller and more efficient. But at the same time, you gotta 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. 

AJ_O’NEAL: Yeah, it really is. 

CHARLES MAX_WOOD: It also reminded me of, uh, somebody who's on this panel who, uh, 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 looking at it and going, okay, how does this actually shake down? And how many people does it help versus frustrate versus actually cause major problems in their coding anyway, and things like that. 

AJ_O’NEAL: So on that note...

AIMEE_KNIGHT: Let me add something to if that's cool. 

AJ_O’NEAL: Do it. 

AIMEE_KNIGHT: I mean, there's also the case of like Angular and AngularJS, 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 AngularJS was going to be like such a massive overhaul for people. 

CHARLES MAX_WOOD: 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 ES5, ES6, where I think AJ in some ways is talking about things like that and 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 the UJS has taken, right? 

AJ_O’NEAL: 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, maybe 90% of your application can run in an old version of Node or, and it's a very small shim to add a prototype to the string. I hesitate to say the word class, but I'm working a lot in Go and Rust now and they don't have classes either, actually. I don't know, but structs, I don't know, anyway. But, you know, you do something like async await and it's not like, Oh, you know, let me bug fix this. Let me, 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, it's not like that you use async-await. 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 and pad that kind of thing where necessary. But I experimented a little bit with async await and I definitely think that you sync await 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 properly, first of all, you have to mix async await 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 promises, 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 async await until they understand the basics first because it's a syntax change. 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 somebody else pointed out that node six is now no longer supported security wise, like 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 async away 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 10 or 12 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 async await and when's the right place for promise. So we'll see how well it helps people contribute to the code, but it at least makes it easier to read in some places. 

CHARLES MAX_WOOD: 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 gonna be on node eight or node 10 or node 12. And so I can kind of count on them having Async Await. And then others, it's gonna be a different story, right? Where it's, you know, folks still on node six. And so it's gonna 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. 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. 

AJ_O’NEAL: So, and something that you bring up here. So GitLab 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 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 GitLab, they were trying to help their customer base and they messaged some changes in a way that really struck people wrong. And I've had that same problem myself, but what I'm getting as you, 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 12. Like you need to have data in order to be able to make good choices about how to best serve your, your user base. And in the case of GitLab. 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 fear about privacy concerns. And I don't think privacy is really the issue as much as it is choice, but there's a lot of fud out there about privacy. And so sometimes things that are 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 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 and maintain our 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 maintainer for a project using GreenLock. You're gonna 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 GreenLog. Because I foresee that 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 get bombarded 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 people know that I may come to a point where I want to 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 so that I can get some stuff set up and let people opt-in and not bother them. 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 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 need to. Because there are security updates that are going to be coming in Node, perhaps Node 14, that I'll be able to let people know, like, hey, if you upgrade to Node 14, you're going to get these 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's, it's very, there's no cognitive dissonance 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 node 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 node 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 node 10 in order to, you know, for this to work. Don't upgrade if you don't have node 10. I feel like that gives me an avenue where I can make a change that'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 everybody can feel good. 

 

If you're looking for specific information about the request, you can provide it. It automatically scrubs passwords and secure information and you can customize the scrubbing as well. Finally, it has a user feedback system built in that you can use to get information from your users. Oh, and I also love that they support open source to the point where they actually open-source Sentry. If you want to self-host it, use the code devchat at sentry.io to get two months free on Sentry small plan. That's code devchat at sentry.io. 

 

CHARLES MAX_WOOD: Yeah. I like the approach of transparency and it's I mean, 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 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, right? 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. 

AJ_O’NEAL: Yeah I mean, the biggest challenge I'm facing right now with GreenLock is I came out with my initial V3 and I got a lot of feedback on it from existing users. Many of them actually were paid supporters on Indiegogo. And I know that I want to set this project up for a couple of things. One, I don't want to have 16 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 deaf. 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 enhanced 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 a hundred or a 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 this web app service that's got the SSL baked in, you kind of want to just be able to get clone the same repo, your starter pack for your project template, and then not have to go edit code. You want to just be able to run a configuration tool that generates a JSON file or copy and paste the JSON file and change a couple of things. You don't want to go in and generate the code. There's what you commit to a repository, and there's what you configure 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, 70% of the files are going to be the exact same lines. And then there's going to be a JSON 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 green lock init, and it actually generates the file for you that has like the 10 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 lock init 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 boom, 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, screen lock defaults, agreed to terms true and NPX screen lock, uh, sites, add my example.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 JSON file, but it makes it so you can use environment variables and Docker 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 is better for everyone and more scalable. 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, I'm 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. This is 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 da da. And I'm like, Whoa, like you can edit the config file directly. Like this, you don't have to use the CLI, but 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. They, you know, they weren't opening issues. They're just, boom. You know, I can, I can see there were some issues that were opened, but, you know, I could see that the CLI usage was helping people. But yet the people that were my biggest fans in some cases really didn't like it. And it was hard to, like, how do I handle this situation? Like, the people that are supporting me, some of them don't like these changes and I wanna make things easy for them. And eventually I kinda had to resolve to, well, some of this is just people don't like it cause 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 staunch like imperative code people. Some people are imperative code people. They want imperative code. You're not gonna change their mind about that. 

AIMEE_KNIGHT: It's like the who moved your cheese book. 

CHARLES MAX_WOOD: 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. 

AJ_O’NEAL: And the reason I'm making the change, like I haven't gotten around to making videos yet, cause 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, my normal client work pretty quickly, but I still intend to release some videos to kind of walkthrough. I mean, particularly it kind of like a migration video, like this is how you're 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 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. Boys are evil. Don't, don't go there. You know, the project is growing up. The project is not as innocent and young as it once was. And, and I'm realizing that there's a variety of use cases that need certain features that, yeah, just the projects growing up guys and gals and others. 

CHARLES MAX_WOOD: 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 the 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 disagree 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, and do that. And then, you know, they can go and they can imperative away at it and you can continue to CLI at it and you know, it's point up where you're at. 

AJ_O’NEAL: 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. Uh, customers that own domains have the email that they put in the who is as the admin contact. And then there was updates about, you know, the, the project things that are important that anybody who is actively using 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 use the project. And I got people putting in their customer email that was perhaps the domain owner and not it, whereas that's not what's intended with, with let's encrypt, it's intended to basically the, the company that's the host is the subscriber email. So anyway, there's some stuff that wasn't quite clear in 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 kind of what I was seeing happening, it looked like it was a lot of Asian email addresses that were 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 the subscriber. For the zero-to-one case, the maintainer is the subscriber. It's for like the more like the thousand case where there might actually be multiple subscribers for some reason like white labeling or that type of thing. So that just needs to go further down in the documentation and it needs to print out to the screen to say, hey, this email address is being used as a maintainer email and as the 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 and just making a couple of blind changes here and there made the configuration simpler. I think I might just skip version 3.2 and go straight to version 4 because of the feedback I received and the changes I need to make in the API are just different enough that I'm thinking v3 might just only live a couple of weeks. And we might just go straight to v4 for the refinement that needs to be there to help the most people. So I got the readme 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, S3. 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, like 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 node 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 a 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 are 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. 

CHARLES MAX_WOOD: 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? 

AJ_O’NEAL: 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 they're it's, it's a strange thing in open source, but if you want to have a project be sustainable and 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 just have in your mind a way to keep true to your open source ideals, to the self-hosted movement, the 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 project supported and make the transition smooth. So you're not going from a non-scalable, non-hybrid cloud product to one that is having to mess up an API or upset people that otherwise would have been happy if that's what they encountered earlier on. 

CHARLES MAX_WOOD: Sounds good. 

 

A few years ago at a JavaScript conference, I was approached by Nader Dabbitt. And you might know him from the React Native radio podcast. He's also a developer evangelist for Amazon. And when he came to me, we had a conversation about React Native. And the thing that I love about React Native is that it's approachable, it's web technology, and it's cross-platform. And it makes a lot of things really easy for developers to jump in and do interesting things on mobile with JavaScript. So we've had this show now running for several years, React Native Radio, where we interview people about the React Native ecosystem, some of the things that are coming out in React and how they affect mobile and other options that you have for mobile development. So if you're doing mobile development, you're doing it in JavaScript, you're looking for a good option, or maybe you're just trying to stay current with React Native, then go check out React Native Radio at reactnativeradio.com. 

 

CHARLES MAX_WOOD: All right. Well, let's go ahead and do picks. Amy Do you want to start off with the picks? 

AIMEE_KNIGHT: Sure. Let's see, man, I have a lot because I've been really busy and haven't been on lately, but, um, I think I'm 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, uh, if you are a React developer and you're using react dev tools, I guess this came out this like late summer fall, I didn't know about it yet, but it's widened this render. So it can show you if you're like in the dev 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 DevTools stuff. So I'll put a link in that. I guess that's gonna be it for me. 

CHARLES; Awesome. Steve, do you have some picks for us?

STEVE_EDWARDS: 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 perusing around and watching that. And I got sucked in like into a vacuum. I watched like four hours at night and the next day I managed to watch another four hours at various parts of the day and I'm watching on my phone as 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 and 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. 

CHARLES MAX_WOOD: Yeah, I watched the first season when it came out and I enjoyed it as well. AJ, do you have some picks for us? 

AJ_O’NEAL: 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 the type of humans that we ought to inspire to be. And if we could all be 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 the way that, I mean, it just seems to be on the rise today. There is, let me get his name right, Daryl Davis. Daryl 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 Ku 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 in a neutral location in a hotel, then 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, 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, Daryl 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 as the grand wizard, like the top dog, the main dude of the Klu Klux 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 know overcome any sense of negative mentality to be able to just be an incredibly powerful person. So I just can't stress enough how important I think the message that that Daryl 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, I'm inspired to be more that way by him. 

AIMEE_KNIGHT: I have goosebumps. That's really good. 

CHARLES MAX_WOOD: Yeah. I'm going to 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. 

AJ_O’NEAL: I think I'm going to leave it with that. I think that that is such a powerful message that I would like that to stand on its own as what I picked this week. 

CHARLES MAX_WOOD: Yep. All right. I'm going to go ahead and jump in with a couple of picks. Now I realized that a, 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 gonna 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 40 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 dad's favorite movies. And since we lost him in 2018, 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 got Jimmy Stewart or James Stewart in it and Donna Reed. And then the other movie that also has Jimmy Stewart in it is Mr. Kruger's Christmas. I remember watching that as a kid. Came out in the 80s. I'm not going to spoil anything about it. I'm just going to let you go watch it because it is amazing. And again, it just kind of personalizes Christmas in a very meaningful way. And, uh, you know, it makes you realize that, you know, w whether it's how fortunate you are or some of the opportunities that you have to make somebody else feel important at Christmas, it's just incredible. So then 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. 

STEVE_EDWARDS: As long as they're not Hallmark movies, Chuck. 

CHARLES MAX_WOOD: 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 sent 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, chuck at devchat.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, Max out. 

STEVE_EDWARDS: Adios. 

AIMEE_KNIGHT: Bye. 

AJ_O’NEAL: Adios. 

 

Bandwidth for this segment is provided by Cashfly, the world's fastest CDN. Deliver your content fast with Cashfly. Visit c-a-c-h-e-f-l-y.com to learn more.