Documentation often gets cited as the main 'semi-techncal' thing to do for an open-source project.
However, I disagree with the point that moribund projects could be revitalised this way. If the people writing the code have little interest in explaining to other people like themselves how to use it then IMHO writing additional text for less involved people is not going to be very impactful.
Your second point about myopic docs is spot on, though. A human-readable summary can be invaluable but it involves getting your head around what already exists first -- that requires some will from the developers in the first place.
I actually ran into this issue with the `argus` network flow generator/processor project, run "by one dude." As a non-developer, but a user, I spent time grinding away at understanding it, mostly as a hobby, and wound up realizing that the "one dude" set his bar pretty high at what he expected of his users' skill sets. I can sincerely appreciate that, but that bar should be lowered so that folks can at least use the software effectively without pissing off the entire mailing list :D
I did just as stated here; lowered the bar for non-developers by producing "on boarding" documentation that takes you from no-to-go in about 30 minutes, massaging my inane questions and failures in mailing list etiquette into an accessible wiki doc (accessible at nsmwiki.org for anyone who is specifically interested).
However, I disagree with the point that moribund projects could be revitalised this way. If the people writing the code have little interest in explaining to other people like themselves how to use it then IMHO writing additional text for less involved people is not going to be very impactful.
Your second point about myopic docs is spot on, though. A human-readable summary can be invaluable but it involves getting your head around what already exists first -- that requires some will from the developers in the first place.