hpr-knowledge-base/hpr_transcripts/hpr3967.txt

Episode: 3967
Title: HPR3967: Unsolicited thoughts on running open source software projects
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr3967/hpr3967.mp3
Transcribed: 2025-10-25 18:05:33

---

This is Hacker Public Radio Episode 3967 for Tuesday the 17th of October 2023.
Today's show is entitled Unsolicited Thoughts on Running Open Source Software Projects.
It is the 20th show of DNT and is about 8 minutes long.
It carries a clean flag.
The summary is, a man talks to himself during his drive home from work.
You are listening to a show from the Reserve Q. We are airing it now because we had free
slots that were not filled.
This is a community project that needs listeners to contribute shows in order to survive.
Please consider recording a show for Hacker Public Radio.
Hello and welcome to another exciting episode of Hacker Public Radio.
This is your host DNT on the tail end of my drive home here.
I just wanted to say a few things and record it.
I don't know if it will sound any good because I guess I'm using the cars microphone right
now.
So I was thinking about the way some of these open source projects are run and I subscribe
to a mailing list from the Password Store project, which is also called the Unix Password Store,
I think.
There are a few different names.
The command is pass.pass many of you will know it.
It's pretty well supported by some other applications that can kind of integrate with it and it's
very easy to integrate things with it yourself because it's just a bash script, right?
It is a password manager that works by just saving your passwords in text files that are
encrypted using GNU PG.
So just using whatever key you want that you created is a very simple thing.
So anyway, every once in a while, so this is one of those projects that's just run,
they use that forge platform that's open source that's made by the same people that
have made Password Store and who also made Wireguard, I think.
And it's also used by the kernel project.
So they just have that mailing list, there's not really a system for creating.
Even like issues or things like that, I think there's, I don't think there is a way to
create like a pull request.
So people will just send patches to the mailing list, right?
Which I guess is kind of like an old school way of doing an open source project, some
people might think.
But it's, and then, you know, everyone's going to know how somebody will come to the mailing
list complaining that they sent a patch, however many months ago, like just the other day
somebody came in, this is June 2023, someone came up saying that they submitted a patch
back in February and had had no reply, right?
And then if you've lurked in this mailing list for a while, you know that there is no
expectation that your patch will be looked at within any amount of time, right?
You basically offer the patch and then you let go of it, I think is what the idea is.
And, you know, maybe the patch eventually somebody will look at it when they're putting
together a new release and maybe they'll look at your patch and then they might include
it in the release or they might drop it.
And then when they do, probably they'll send a reply in the mailing list saying like,
hey, thank you, or maybe saying why they are not including the patch.
And then what I think is interesting, like in this case, it's easy because this application
is really just a bash script, so it's very easy for anyone to maintain their own fork
and just use their own fork, right?
You really don't have to rely on the releases, you know, that's one of the cool things about
it being an open source.
If you have a patch, just apply your patch and use your fork and then you'll share the
patch to back to the project, what they do with it doesn't matter because you've got
the patch in your own fork and you're using it, you know?
So of course, that's not always going to be true in some more complex applications
that maybe you're not going to want to build yourself or whatever, but certainly in this
case, it's very easy to just, you know, make the change you want for your own use and
then, you know, you don't necessarily have to care if it gets applied upstream or not
or certainly you don't have to care how soon it does.
And yeah, this is kind of interesting to me.
It's pretty different from that vibe where you have pull requests and, you know, how many
times have we heard of maintainers complaining about these expectations that are put on them,
like people create issues to complain about something that's not working right, you know?
And, or they'll, you know, create a pull request and then get mad if it's not looked
at, reviewed, and merged within a couple of weeks or something.
And you know, all that the maintainer wanted to do was share what they did for themselves
with other people who might want to use it and now all of a sudden they're in this strange
free customer service situation, right?
So anyway, yeah, I thought that was pretty interesting, it's interesting to think about
it that way, you know, you're, you made it for your own use, the thing, or like if you
think about it, like as a book, maybe you wrote it because you just wanted to say it, I
don't know, and then you shared it and then, you know, whatever anybody else wants out
of it is, I don't know, not necessarily, you're not making any promises about it, you just
shared the thing that you made, you know?
So I kind of like that, I think that's, that's a good way to, to run an open source project,
it's probably more sustainable than these pull request things and, and all of that kind
of a more corporate type of vibe that you get from these forges that people like like
Good Hub and all the others that are that look the same.
Yeah, I find that pretty interesting.
So anyway, that's what I wanted to share in thinking about that a little bit in the
last few months and then recently I saw there was another case of somebody complaining
about their patch not being merged to make a new release, so I thought, oh yeah, there's
that thing again, maybe I should get the microphone going and talk about it and then post
to HPR because it was going to stop me, right?
So anyway, that was that.
So you know, if you're driving home and you got your phone with you and if it's safe enough,
you can pull out your phone and start recording an episode of Packer Public Radio sharing with
us these things that have been on your mind just like I just did.
I would really appreciate hearing you share your thoughts in that way with us here in Packer
Public Radio.
Alright, thank you for tuning in and come back tomorrow for another one of these.
Bye.
You have been listening to Hecker Public Radio at Hecker Public Radio does work.
Today's show was contributed by a HPR listener like yourself.
If you ever thought of recording a podcast, you click on our contribute link to find out
how easy it really is.
The hosting for HPR has been kindly provided by an honesthost.com, the internet archive
and our syncs.net.
On the Sadois status, today's show is released under Creative Commons, Attribution 4.0 International
License.