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)
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.
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.
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)