I knew someone would say that haha. Let's rephrase what you said in a general context to show what the problem is:
"Anytime you're evaluating solutions to a specific problem in your system or code you should look at all the source code people are posting without expecting a description of what it does. Just read all the source code out there, guess if it meets your needs, and then try whichever looks right."
Kind of dumb way to go about finding 3rd party libraries or tools. Similarly foolish to expect it unless one simply doesn't care about adoption at all. The alternative, which my comment promotes, is to have relevant data in a short summary on each projects' page. Google, HN, or whatever finds users/developers a set of pages like this. At a glance, they can tell what's worth further investigation. Then, they look at its code. Much better way to use limited time to find needles in the massive haystack that is the Web.
I get where you're coming from, but the entire tarball contains one source code file and it's a paltry 89 lines in 1317 bytes. Heck, the man page is a whole 70 bytes bigger than the source code. This is very, very different from, say, Django. I'm not advocating for... whatever it is you're claiming w.r.t. needles and haystacks, only a wee bit of situational awareness when you've already gone so far as to download the code.
And Suckless? Yeah, they're basically the definition of "doesn't care about adoption at all".
"Heck, the man page is a whole 70 bytes bigger than the source code. This is very, very different from, say, Django. I'm not advocating for... "
Alright, alright haha. Yeah, I did download the code. It was small and seemed understandable. Seemed as there's no telling what assumptions its built against. I've seen code meant to prevent compiler issues, OS issues, timing channels... all sorts of things you wouldn't know just reading the code itself & might have even scrapped. So, I'm still about code coming with a detailed statement of what it does with what environmental assumptions.
On other hand, this could be so plain that the environment or tools don't matter. Maybe.
"And Suckless? Yeah, they're basically the definition of "doesn't care about adoption at all"."
Their page hints at targeting a demographic of pro's tired of bloated BS. I wasn't sure how much they cared. There's some clarification.
I wouldn't say you should read all source code out there; but this is just 89 lines of fairly readable C code. Even its man page (the .8 file) is larger!
"Anytime you're evaluating solutions to a specific problem in your system or code you should look at all the source code people are posting without expecting a description of what it does. Just read all the source code out there, guess if it meets your needs, and then try whichever looks right."
Kind of dumb way to go about finding 3rd party libraries or tools. Similarly foolish to expect it unless one simply doesn't care about adoption at all. The alternative, which my comment promotes, is to have relevant data in a short summary on each projects' page. Google, HN, or whatever finds users/developers a set of pages like this. At a glance, they can tell what's worth further investigation. Then, they look at its code. Much better way to use limited time to find needles in the massive haystack that is the Web.