3 ms·

That's not why corps eat up Confluence. My day job is Atlassian crap and I move people off of other OSS wikis into Confluence all the time. Corps just run into

• evgen 11y ago
  Like what? As someone maintaining a Confluence wiki among other tasks I can say the only thing I has provided is reasonably fine-grained access control and a huge ton of headaches, pure WTF moments of XML hell, and java crash stack traces to debug. Confluence is the Wordpress of wikis, but without Wordpress's code quality</s>
  • Karunamon 11y ago
    Only time I've ever run into XML hell on Confluence is when dealing with imported pages. Their automated import tool is neat, but it leaves you with some cleanup to do since not all of the markup from $wikiPackage transfers cleanly to Confluence macros. 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)
  • devonkim 11y ago
    You want this alphabetically for why most corps won't deploy OSS wikis that are stamped for approval by the HN crowd? 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