
Show HN: Interviews with open source maintainers and developers - Jefro118
https://sourcesort.com
======
Jefro118
Hey, "editor" here. When I started working as a developer a few years ago, I
barely considered that there were people devoting their free or paid time to
all of the open source software I depended on. Of course, every piece of
software you depend on has one or more humans behind it, and they have stories
to tell which might be instructive for others. Hence this site (the framework
for which is heavily inspired by IndieHackers).

I have 3 main goals with SourceSort: 1) discover and share best practices (and
learnings from failures) for other open source maintainers and developers 2)
promote the projects and maintainers I interview and 3) Satisfy intellectual
curiosity. I hope I've managed all three with this first set of interviews,
but I'd love to hear any feedback.

And thanks to all of the developers who took part in this first set of
interviews, all of whom have been very friendly and generous with their time.

(p.s. if I interviewed you and it isn't up yet, don't worry - I'll get them
all finished before the weekend)

~~~
souprock
Have another:

I maintained procps from roughly 1997 to 2007. (do "man ps" and search for
"Albert")

I started because I insisted that mixed syntax like "ps x -f" and "ps u -u u"
could be parsed and be useful. I wrote the code to prove it, got in a conflict
with the existing maintainer after Debian was already using my code, forked
the project, and won.

The early days were wild. I was less experienced and it was a different era. I
would write the code late at night in my dorm room. I didn't yet have
regression tests, so one release went out that hid all processes whose PID
started with the digit "3".

Usage growth was dramatic, with the package being chosen to be in the default
install for all Linux distributions.

The community was difficult. I had one reliably helpful person, the Debian
package maintainer Craig Small. I had somebody show up with a rewrite of
"top", which I regretted accepting. It was overly complicated, then abandoned
by the author when I insisted on compatibility with older config files. I got
random patches here and there. Package managers for most Linux distributions
turned out to be kind of hostile, doing things like adding bugs and swiping
command option letters that I had reserved for other purposes.

The workload put an end to my involvement. I was able to manage with 3 kids
and a job, and I was able to manage with 5 kids and no job. Things started to
fall apart with 5 kids and a full-time job at a startup, and then really fell
apart when I added another kid. (am at 12 kids now) I had no time to respond
to email or work on the code, and I never did resolve the problem of
incompatible patches being applied by Red Hat and others.

There were probably weeks I put in more than 40 hours, and there were many
weeks when I did nothing. Perhaps 10 was near the average, but it is hard to
say.

Other than time, the biggest obstacle was the inability to keep Linux
distributions from hacking things up. They would add crasher bugs, and then
I'd go fetch their modified package to find out what had been done. They would
change behavior, sort of making a proprietary interface. There is simply no
possible way to say "no" to a Linux distribution and have it stick.

My hopes will probably be dashed now that I am not involved. I liked how "ps"
would concisely print a help screen that covered the key options, but that is
now gone. I liked how "kill" was capable of sending a signal to PID -1 for
signalling everything, but that was broken last I checked. (still in the man
page though) I liked the fact that "ps" avoided default sorting so that it
could run on systems that are low on memory (a good reason to run "ps") and so
that it could produce at least partial output on systems having kernel lock
trouble. I liked having low CPU usage by "top" itself, partly due to parsing
64-bit ASCII decimal with a custom parser and partly due to doing word lookup
with perfect hashes and computed goto. Letting go has been hard, but I simply
don't have the time anymore.

The advice I have for other open source projects and maintainers is to prepare
better for the day when you can't work on the project. Document the reasoning
behind design decisions, including for things that are purposely left out.
Documentation usually covers things that exist, but it also needs to explain
why things are deliberately missing. Be sure that your successor will have
your extra odds and ends, like test suites, even if you suddenly go missing.

~~~
Jefro118
This is really interesting, great to read about a project that started in a
slightly earlier period.

Did you want just to share this with HN or to go up on the website? (Happy to
put it up if so, I think a lot of people would find this interesting)

~~~
souprock
It's up to you. I followed along with your questions, in the typical order, so
you can just add in the matching headers if you like.

The notable difference is that I'm a former maintainer. Also, it was core
system utilities written in C.

------
sillysaurusx
[https://sourcesort.com/contribute](https://sourcesort.com/contribute) is an
interesting list. How is it generated?

I'd love to hear a bit about the backend code too: how the search works, what
stack powers the site, any libraries/tools you find indispensable, etc. I like
the minimalist design.

~~~
Jefro118
Projects are found using the GitHub API, searching for projects first on
whether they have issues labelled for new contributors and then also by
language, topics, etc. After that you can write a bit more code to get metrics
like percentage of first time pull requests accepted, median time until a
maintainer responds to a new contributor, etc. Results are then placed on an
Algolia index (stored in Postgres first) which is what powers the search +
Algolia React components.

For the interviews, I write/edit them with a self hosted version of Ghost and
then use their webhooks to sync them with my own Postgres database (I need to
add extra fields like for projects/people and Ghost doesn't allow you add
custom fields yet).

Backend is Node.js/Express, I just use EJS templates for the other less
interactive pages since I think React would be overkill there.

I was until this morning hosting it on Heroku but switched over today to Dokku
+ DigitalOcean (mainly because I have a load of free credits and didn't want
to end up with a large bill in case this hit the top of HN). First time using
Dokku and it's pretty great.

Besides the GitHub API, which I need to get the project info, I wouldn't say
anything else is indispensable. Heroku/Dokku is pretty important because I'm
not much an expert with managing servers.

Glad you like the design, I think the search UI could be better. For the
interviews I just tried to focus on typography first and foremost. Matthew
Butterick's Practical Typography is a great book for reference.

That's a lot of info, hopefully not too much. Hope it's informative!

~~~
tropo
The search UI needs negations.

For example, you offer a checkbox ("Code of Conduct") to select projects with
lots of nasty political fighting to distract from the engineering effort.
Maybe somebody would rather focus on nerdy hacking.

Another example is "Has full documentation". That is a bad thing if you want
to contribute by writing documentation.

~~~
Jefro118
Yep, those are fair points. For documentation (and for other things) it would
be better to be able to search on that directly by e.g. looking for projects
that have open issues around documentation. Will try and add these soon, I've
just been focused on the interviews recently.

------
JMTQp8lwXL
It's good to see new voices. I often see the same names in my particular niche
within open source.

~~~
Jefro118
Which niche are you in if you don't mind me asking? It's only been a few
months of me trying to get more involved in open source myself and I'm still
trying to understand better how these ecosystem/communities work.

~~~
JMTQp8lwXL
Front end / JavaScript.

------
panpanna
Linux Voice (RIP) did non-technical interviews with famous devs on the last
pages. I learned some very important things from those interviews.

(back issues are freely available )

~~~
Jefro118
Thanks, I'll look it up for comparison. What was it that you learned from them
if you don't mind me asking?

~~~
panpanna
How they work, what tools they use, how they organize their life so they have
time for FOSS development, that sort of stuff.

