Things don't need to be explained from base principles or anything like that and as you mentioned they're not beholden to anyone, but explaining to a bit broader of an audience than one's particular niche is still generally a good idea. It makes it easier for people not-in-the-niche-but-somewhat-close to be able to understand/evaluate things. It could be a project that's relevant to this near-to-the-niche person, but without somewhat broader explanation, they'd miss it.
Another good idea (that no one is obligated to do) for project descriptions/overviews is to give a brief mention of why. For instance, it would have been nice if the readme for this project mentioned the purpose being "To bypass all non-essential hardware, and process it all in software directly for an affordable and simple way to create a true 1:1 archival copy of analogue tape mediums." It wasn't too hard for me to dig a bit into the project wiki to find that out and piece it together, but I'm used to doing so, specifically because so many readmes tend to not do it themselves.
Finally, you've said "they owe you nothing" and I've also noted the lack of obligation, but while technically/legally true, there are still some expectations and unofficial obligations to varying degrees when releasing open source software. Generally, the more useful/interesting the software is, the more expectations and unofficial obligations there are. Take for instance any software that has a benevolent dictator for life (BDFL) scenario. That term on its own has expectations of benevolence built-in. There are expectations that they'll guide the project in good directions, that they'll ensure bugs get fixed, and to some degree that the community will have some input on things even though the BDFL makes the final call. More generally on most projects, there are expectations that bugs will get fixed, pull requests considered/merged when appropriate, documentation will be provided, and so on. It's hard (perhaps impossible) to have a successful open source project that does not do these kinds of things, so in a real-world practical sense, there _are_ obligations in open source projects, if you want any kind of success for the project.
Another good idea (that no one is obligated to do) for project descriptions/overviews is to give a brief mention of why. For instance, it would have been nice if the readme for this project mentioned the purpose being "To bypass all non-essential hardware, and process it all in software directly for an affordable and simple way to create a true 1:1 archival copy of analogue tape mediums." It wasn't too hard for me to dig a bit into the project wiki to find that out and piece it together, but I'm used to doing so, specifically because so many readmes tend to not do it themselves.
Finally, you've said "they owe you nothing" and I've also noted the lack of obligation, but while technically/legally true, there are still some expectations and unofficial obligations to varying degrees when releasing open source software. Generally, the more useful/interesting the software is, the more expectations and unofficial obligations there are. Take for instance any software that has a benevolent dictator for life (BDFL) scenario. That term on its own has expectations of benevolence built-in. There are expectations that they'll guide the project in good directions, that they'll ensure bugs get fixed, and to some degree that the community will have some input on things even though the BDFL makes the final call. More generally on most projects, there are expectations that bugs will get fixed, pull requests considered/merged when appropriate, documentation will be provided, and so on. It's hard (perhaps impossible) to have a successful open source project that does not do these kinds of things, so in a real-world practical sense, there _are_ obligations in open source projects, if you want any kind of success for the project.