| They owe you nothing, so if you want to figure something out, searching the web is your best chance. Also, how is it not clear what the project is? First thing I see from the submission link: > Software defined VHS decoder > A fork of LD-Decode, the decoding software powering the Domesday86 Project Which links to https://github.com/happycube/ld-decode and https://www.domesday86.com/ > Software defined LaserDisc decoder and > Domesday86 is a project that aims to recreate the experience of the original BBC Domesday project using modern hardware and software Which leads me to searching what BBC Domesday is, as I didn't know: > The BBC Domesday Project was a partnership between Acorn Computers, Philips, Logica, and the BBC to mark the 900th anniversary of the original Domesday Book, an 11th-century census of England. It has been cited as an example of digital obsolescence on account of the physical medium used for data storage. Not sure why everything has to be made for/explained as it's made for literally everyone. Some software is for a niche section of programmers/developers/$niche-group, that's perfectly fine. If you're curious, use a search engine like the rest of us. |
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.