I like to call Confluence a knowledge cemetery - in the huge datasets you have in mind, finding the page you are looking for is more a matter of luck than anything else. And once you found it, you can never be sure if it's still up to date.
> Anyway, they have 8000 employees... they can always drastically downsize and refocus, the company will be around for a while.
I'm actually wondering how they can not make a profit with the huge corporate user base they have?
Spot on from my experience using it in big orgs.
The issue IMHO is that organization of knowledge is not following any system and/or no system that could be followed was ever set in place by the organization when they bought into Confluence.
It's kinda like ordering an Airbus because they're a reliable plane. Then you sell tickets and everyone is board of course because ... Airbus. But you never hire a pilot.
If organizations using Confluence had at least one full time "Wiki Master" position or the like (with resp. superpowers), this wouldn't have to be like that.
I.e. I'm not sure the argument can be made that this is Atlasassian's fault.
As someone who spends a lot of his work life administering Jira and Confluence, I disagree. The problem is that these products try to be everything to everyone and as a result users have a massive degree of freedom with what to do and how to order things.
With that amount of freedom you just have a bunch of end users, many of them non-technical, who have no idea how they are SUPPOSED to use it. Especially because they don't want to spend a lot of time learning the right way to use the tools. They have a bunch of other things to do and just need to interact with this tool to complete their current task and then move on.
You are right, a sort of Wiki-Master would help. But, at least in my organization, we don't even have enough capacity to do all the basic administrative tasks required like setting up projects, workflows, custom fields, screens, etc. We can't also manage the content inside. The users are on their own in that regard.
If you are not willing to hire stuff with the sole purpose of managing the content of your Jira and Confluence instances, a more opiniated, rigid product is probably a lot better for your organization.
I think part of the challenge is finding and retaining this person. It takes a fairly unique kind of person to want/enjoy a (let's be honest) thankless job like managing and maintaining a huge corporate wiki.
Finding good tech writers or information science professionals has always been a difficult task in any company I've been at.
Documentation and wiki writing ends up being side-of-desk work for someone else, and so of course it never gets maintained.
Jira - Everyone has the performance issue, to avoid it they tell them to carefully choose extensions and not randomly litter it, especially with extensions that conflict each other.
Confluence - They recommend to establish a proper structure in advance that everyone follows with templates that everyone can use(not the default ones), so that the cemetery issue doesn't happen.
That said, I haven't seen any company who's confluence wasn't a knowledge cemetery. But regardless of how much I dislike Jira, I'd still pick confluence over google docs.
But what about storing documentation as flat files in version control?
What about even storing tickets as flat files in version control?
It eventually got replaced by some JIRA-like monstrosity, I don't remember which. All the text-based goodness was lost. The excuse for the move to a different system was "performance", which was half true. I'm guessing that nobody wanted to go fix it.
The point behind all this rambling is that yes - flat files can be made to work in the way you mention. It just isn't an approach that is cool enough.
I agree that any approach should not have many hurdles!
I've been using https://github.com/just-the-docs/just-the-docs and find it much easier, nicer looking, and people are excited to not use Confluence.
Of course it doesn’t apply just to confluence, but to the whole paradigm of uncurated, informal knowledge dumps.
Unless there is a real process around documentation, it just rots, and the key problem is you can tell what’s fresh and what’s rotten.
