Show HN: Interviews with open source maintainers and developers(sourcesort.com)
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)
How do we submit topics/projects/interviewees? I run https://github.com/browserless/chrome and would love to chat about the subject!
Ah I should have added that - email me on email@example.com. I know your project too! Would be cool to learn more about it.
Thanks for sharing the details. I've started something similar to this idea but target audience is students who need guidance.
Would be great if you could share some advice on contacting people and getting stories.
Hi there, I actually found most of the projects either here on HN or on GitHub explore, and a few of them I thought of because I used the projects myself (e.g. Brian of node-postgres). Quite a lot of developers put their email address on their GitHub profiles, or otherwise their personal website, so contact info was easy to find. Maybe that's more difficult for students than maintainers though?
For the email, I was just straightforward in saying what I was working on, what I hoped to get out of interviewing them and what I hoped they would get out of it. And I did the interview over email which made it easy for them.
Your content is good, although if I could give a small criticism it would be on your typography - the pink headings in all caps with big letter spacing just makes it much harder to read, and I would make the body text a little larger too. (this site is great for reference: https://practicaltypography.com)
Best of luck and happy to answer any more questions.
Thank you for your suggestions and the reference. It'd be really helpful. Wish you good luck too! I'm definitely taking some cues from your site too!
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.
This was really eye opening, thank you for sharing.
What really resonated me is about documenting what to leave out. To keep something simple, you really need to say no to a lot of things. People by default think you don't know anything about it and why they like it.
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)
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.
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.
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!
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.
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.
It's good to see new voices. I often see the same names in my particular niche within open source.
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.
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 )
Thanks, I'll look it up for comparison. What was it that you learned from them if you don't mind me asking?
How they work, what tools they use, how they organize their life so they have time for FOSS development, that sort of stuff.