The problem I see is the SO is a substitute for well written documentation, rather than an incubator for quality technical writing.<p>It depends on open source docs being poor so noobs need experts to educate them. But it does not place a burden on the experts to improve the original docs.<p>For example, Python peps and standard library docs are often painfully and needlessly laborious, such that it's often easier to just read the code. Similarly, the git manual is written to induce episodes of acute madness.<p>The SO solution? Read a thousand piecemeal SO answers, get the job done in a slapdash way, get paid. Don't worry about the inaccessibility, waste, and exponentially accruing technical debt of the whole enterprise.<p>Priests of this cult often avoid reading the docs, and never pick up the responsibility to improve the awful docs.<p>The SO high priests will gladly regurgitate their knowledge like mother birds, often in writing as bad as upstream docs. Typically defending and normalizing the inaccessible upstream docs.<p>It's an accessibility nightmare.<p>You end up with millions of inefficient and insular tidbits whose sum is somehow less than the whole. It's designed to make users dependent, rather than free them.<p>It feels like there was a time where SO could have become more. But doing so would have lessened use reliance on SO, and required answerers to improve upstream docs. They chose to be self contained and derivative, rather than transformative to upstream projects.<p>It will be dismantled.<p>Now SO has so much entropy that it's only good for AI reprocessing into docs for upstream projects.<p>Thankfully much of SO knowledge is now bundled into LLMs. So getting actually legible docs is usually as easy as pasting the project docs and asking for an organized and straightforward docs.<p>The challenge I see is closing the loop and ensuring upstream docs improve. The culture of inaccessibility is too entrenched for SO to do this - the org's revenues would have to collapse. But AI can work to the advantage of an accessibility focused upstart. They can liberate, mobilize and reintegrate the captive knowledge of the SO corpus. They can push it back into open source project docs.<p>And in cases where upstream prefers bad docs? The upstart should fork the project and take responsibility for project accessibility.