I find these solutions actually make documentation harder. They're binary and proprietary in nature, locked behind a paywall if I can no longer afford the service (and what's the exportable data going to look like? XML?), And the UI is often limited and leaves a lot to be desired.

My code is not binary, however, it's plain text. So I write my documentation in plain text too, such as Markdown. That can, should I so choose, be rendered to anything I like. It can be included alongside the code, which the developer will need a copy of anyway, and be easily reviewed (with "mkdocs serve" for example).

You're already committing code to a central repository and working in a decentralised manner. If you put your documentation in "./docs/" (I recommend MkDocs + the Material Theme) and commit it, then everyone has access to it immediately. It's free, close to the code and in context, everyone who needs access to it has it, and it's simple to use. It's also local, extremely fast and, if desired, can be easily embedded into a CI pipeline, compiled to anything you like (Markdown => *) and pushed to wherever you like.

I also don't understand the obsession with making documentation available online, 24/7, when we live in a cyber security nightmare right now (https://www.hertzbleed.com/; https://securityboulevard.com/2022/06/apple-m1-flaw-cant-be-...; https://www.darkreading.com/threat-intelligence/emotet-banki...; https://www.darkreading.com/edge-articles/turbulent-cyber-in....)

Just keep it within context, plain text, and easily convertible to other formats. Try not to over think things.