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