I'd short it technically because Confluence is Satan's wiki, but corps eat it up because WYSIWYG and because it costs money. (FOSS is bad, doncha know).
Personally, I'd be happy with just Markdown if it was just a group of devs, but that is a rarity. At my company now, we have tech support, IT, (non-technical) account reps and even to some extent HR and finance using it, and to get that to happen, it was essential to be very easy. There's still a handful of users that attach Word or PDF documents to a page, but at least it's accepted that the wiki is still the canonical location to get any type of documentation, company policy/forms, etc. Baby steps.
So well Confluence does have its warts, getting buy-in into non-technical departments trumps those.
Conversely, I've never seen a non-WYSIWYG wiki actually successfully deployed and used by non-technical users (as contributors) -- anyone else?
Confluence is just tacky, too much whitespace, whizzywig editor is slow and buggy (less so than 2yr ago).
And the old fogeys on the team that hate documentation still write their notes in a notes.txt file on our team share. Having a "beginner friendly" wiki didn't help anything.
Oh, and our dokuwiki was HA on day one, with backup scripts zipping and SCPing a backup to an offsite server. Confluence took MONTHS to get HA as an enterprise solution.
I mean you're already doing documentation, adding tedious tasks to it just makes it worse. Ctrl+C, Ctrl+V, done.
Your "old fogeys" thing is a managerial/personnel problem, it has nothing to do with the software.
And this is the first time that I've heard "too much whitespace" be a complaint. You want to be distracted from the content?
I agree that team members not adhering to doc standards is a human problem.
Confluence used to have regular wiki syntax plus WYSIWYG for non-geeks, but the non-WYSIWYG appears to have been killed off completly. It's till a wiki, but barely.
That applies to nearly everything they make, Jira, Confluence, the whole lot.
It's possible, and very very easy, to set up a shitty Confluence wiki, and some of the details of its performance are not exactly obvious. It takes a bit more work to set up one that's both well liked and easy to use.
If I had it to do over again, I'd still pick Confluence over MediaWiki every day of the week and twice on Sunday. Life's too short to deal with wiki markup by hand.
The unfortunate thing with any Wiki or document sharing tool is they tend to become cesspools of outdated or contradictory information. It has to be someone's job responsibility to keep it updated and curated.
2) Agreed on the maintenance part. There needs to be a yearly audit/testing of procedures to make sure the docs hold up to new versions of software, new releases, etc.
My startup's building wiki software that's targeted at small groups to start who want a team wiki (instead of having to post everything to the entire corporation). The idea is to really focus on making the publishing and discussion experiences delightful.
I'd love to chat with anyone who is thinking about setting up a wiki for their startup or team My email is andy@tettra.co and the site is http://tettra.co.
Corps just run into roadblocks with OSS wikis.
Confluence is the Wordpress of wikis, but without Wordpress's code quality</s>
1. LDAP support
2. SAML / SSO support
3. RBACLs
4. Auditability that integrates with some Big Corp compliance system (I'm thinking SOX primarily here and why some companies can't use Git for systems that require full auditability just because Git rebase and wipe of the reflog can happen)
5. The fact it's Java-based rather than oh... Erlang or Python is a pro to most enterprises that have hordes of people that have known only Java tooling and languages. Training a bunch of people that are not motivated to learn anything new is insanely hard. PHP could substitute in here as well I suppose.
6. Other software suites that integrate tightly with it. JIRA sucks for a lot of people, too, but it sure beats all the other crap I've had to use at work. I think less than 20% of the people on HN have actually had to use HP Quality Center or Rational ClearQuest on a daily basis for a long time.
7. Vendor is software maintainer. Big Corps would rather work with a single vendor if possible rather than some small consulting companies that install and integrate the software tailored for their environment and then leave pretty much. So unless one of the primary maintainers of I dunno, Redmine, started offering support contracts with a team of professional services folks, there's hardly any actual competitors to the Atlassian suite in the enterprise "more money and not much technical know-how to spend it effectively" software market.
8. A sales team that you can choke to bend to your will with money. Most OSS projects will not take terrible, horrible, ugly feature requests for large sums of money from a single user that are technically bad and tough to support without massive costs - this is how a lot of enterprise software vendors do business and part of how they decline over time (too many one-off feature requests for big ticket customers that create conflicting design requirements to engineer around combined with a shift to sales culture over engineering / innovation culture leading to massive loss of technical talent).
Edit for newlines
Combine this with the fact that there's no error handler for broken pages - if the XML that makes a page work is invalid on the back end, the page just straight up won't render and has to be fixed another way. (Which sucks, but as I said, this is not a thing most people will ever encounter). It's not possible to generate invalid XML using the WYSIWYG editor, but plenty possible if you're using either the code editor, or plugins that do strange things.
The logs are chatty as hell and you'll generally get stack traces for even completely benign problems/notices. That's one thing I wish they'd deal with, but it's pretty minor.
If you're getting error-level stack traces and XML nonsense on a daily basis, something is terribly wrong in your instance. That is simply not standard behavior, and I'm kind of curious what their support people are telling you.
(Shoot me an email if you're comfortable doing so - I may be able to help you out)
Only thing that I don't know of free software replacement is the Agile Development tooling that JIRA provides. But tbh, "agile development" is a hellhole of buzzwords, expensive consultants and ridiculous bullshit rules anyway.
Unlike Github's mostly developer centric issue mechanism, Jira is more suited for organizations the would have a QA department, a security review, a more complicated release process (multiple phases of validation and testing) or that that just need a custom issue state machine.
It just so happens that those companies also have money to buy Jira licenses and Atlassian is brilliant for letting OSS project use it as well. So they get a foot in the door at multiple places in the industry.
If startup developers don't like it, oh well, there is enough money for them to be made in the Enterprise market.
(Also, I noticed that there is an interesting plugin market for it as well, once you have audience that paid so much to use it, they'll be willing to shell out a a few hundred more for say Slack integration or other such plugins).
Sounds like all the developers you know hate how their bosses use tools. I happen to love how my team uses Jira.
It is almost NEVER brought in by management.
The only exception is if Jira is used for project management type stuff - those projects can and should be isolated from dev projects.
Much happier with Trello and a zero bug policy.
Oh, why hadn't I thought of that...
Up to you if that's a bug or a feature.
The interesting thing is that it is very often used for Agile project management. It's massive overkill for that. It has the feel of something that evolved from an issue-tracking system, because it existed before Agile and morphed into an Agile tool.