Show HN: Interviews with open source maintainers and developers

How do we submit topics/projects/interviewees? I run https://github.com/browserless/chrome and would love to chat about the subject!

Thanks for sharing the details. I've started something similar to this idea but target audience is students who need guidance.

Sample piece:

https://www.freshgrads.info/post/meet-prashant-kikani-who-ka...

Would be great if you could share some advice on contacting people and getting stories.

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.

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!

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.

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