I don’t know if you’ve used Confluence or similar Wiki tools in your enterprise. When I first encountered it, I thought it was great: powerful features, support for various formatting styles, ability to insert images, videos, icons, and view historical versions—the user experience was far easier than Git.
But slowly, I discovered a huge problem: everyone can create and maintain their own Wiki pages.
Initially, this freedom seemed like an advantage. But over time, problems arose: the same topic might have multiple versions written by different people. Especially when projects or products are transferred from one team to another (common in multinational companies), new team members may not continue maintaining the original documents but instead prefer to start from scratch, recording their own understanding.
As a result, old Wikis become obsolete with personnel turnover (the original authors may have already left), and the new Wiki content is incomplete or even inaccurate. Knowledge sedimentation is not only ununified but even more chaotic.
I’ve always believed that Wiki tools themselves are good, but without a unified management mechanism and a Pull Request approval process like Git, they easily become breeding grounds for garbage information.
In contrast, open-source communities do a much better job.
Take the Python community as an example:
- The content of the Python website https://www.python.org is maintained through the GitHub repository python/pythondotorg;
- The content of the developer’s guide https://devguide.python.org is hosted on the GitHub repository python/devguide.
Anyone with suggestions for modifying these documents must submit them via PR, which undergoes review and CI checks before merging. Moreover, because it’s an open-source project, community users actively participate in feedback and improvement, helping to maintain high-quality documentation over the long term.
But in contrast, inside enterprises, it’s completely different:
- Multiple people write their own Wikis, resulting in inconsistent quality;
- Many content silos lack maintenance; once personnel turnover occurs, old documents become “obsolete”;
- More importantly, internal documentation lacks a public review mechanism and external feedback channels, making it difficult to detect or correct errors.
Another point might be more realistic and brutal: within enterprises, employees lack the motivation to maintain documentation. Because a meticulously written, flawless “perfect document” might one day mean you can be “seamlessly replaced.” In contrast, keeping key details in your own head provides a greater sense of “job security.”
Therefore, document governance is fundamentally not about tools but about people. Without cultural and process support, even the most advanced tools can become dumping grounds for information garbage.
Documentation and code are inseparable. My experience in the open-source community has taught me: truly excellent individuals often single-handedly support a team’s quality and rhythm. They are passionate about technology, take proactive responsibility, and are willing to share, driving healthy project development.
In contrast, problems in some enterprise projects often stem from the opposite direction. When team members lack a sense of ownership, personnel turnover is frequent, or individuals with mediocre abilities have the most opinions, the result is only more piling onto the legacy codebase.
Finally, have you had similar experiences? How does your company manage internal documentation and code? Please share your thoughts in the comments.
Please indicate the author and source when reprinting this article. Do not use it for any commercial purposes. Follow the WeChat public account “DevOps攻城狮”.