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.