Overall I think you're correct, but I want to add some color to your comments:
Integration with other software is going to depend on a per integration basis. Some integrations are done by Atlassian themselves. Some are done by the other software provider. And some are done by third parties. Slack is a great example where the integration is owned by Atlassian, but there are also third party alternatives. The "quality" of these integrations varies, in large part depending on what your specific org needs. In the Slack example, the Atlassian integration has no support for creating issues in Jira from Slack. This is a use case that a small subset of customers want. Does that make the Atlassian integration bad? If you have specific integrations that you are frustrated with feel free to shoot me an email and I can dig into it. Especially if it is made by a third party provider, we're a really tight knit community and I can likely email their CEO and see if things can be improved for you. Or hell, it may even be one we make and something we need to fix :D
The UI is slowly improving, but yes it is not the most intuitive thing in the world. It is also a 16 year old piece of software, where if you look at the UI, the chrome has changed, but the structure has been fairly stable.
Performance is a topic near and dear to my heart. I have given a number of talks about this and for a long time our company branded itself as the "performance and scale" experts for Atlassian software. With good governance, and qualified admin skills, Jira and Confluence can be "fast enough" in terms of enterprise software. Will this be web scale speeds? No. Does achieving web scale speeds provide value for 95% of users? No. The thing to do here is to improve integrations to reduce the amount of application switching that users are doing. For example, if you're a dev, use Smart Commits[1] to interact with your Jira issues as part of the commit message. No going into Jira or BB in the first place.
The editor in Confluence has been a work in progress in Cloud, but they're hitting a lot of issues. Part of the issue here is that providing an editor that is both friendly to an HR person, and to a dev is a complicated challenged. When Atlassian deprecated Markdown from Confluence, I was working for them at the time and published the Markdown Macro for Confluence [2] as a ShipIt project (internal hackathon). This has helped thousands of orgs interact with Confluence via Markdown. At the same time, we're building a Drag and Drop editor for Notification Emails in Jira, and holy moly are there a lot of edge cases and problems that we hit. There are entire businesses that do nothing other than sell make and sell editors. I wouldn't underestimate the complexity involved in this.
Integration with other software is going to depend on a per integration basis. Some integrations are done by Atlassian themselves. Some are done by the other software provider. And some are done by third parties. Slack is a great example where the integration is owned by Atlassian, but there are also third party alternatives. The "quality" of these integrations varies, in large part depending on what your specific org needs. In the Slack example, the Atlassian integration has no support for creating issues in Jira from Slack. This is a use case that a small subset of customers want. Does that make the Atlassian integration bad? If you have specific integrations that you are frustrated with feel free to shoot me an email and I can dig into it. Especially if it is made by a third party provider, we're a really tight knit community and I can likely email their CEO and see if things can be improved for you. Or hell, it may even be one we make and something we need to fix :D
The UI is slowly improving, but yes it is not the most intuitive thing in the world. It is also a 16 year old piece of software, where if you look at the UI, the chrome has changed, but the structure has been fairly stable.
Performance is a topic near and dear to my heart. I have given a number of talks about this and for a long time our company branded itself as the "performance and scale" experts for Atlassian software. With good governance, and qualified admin skills, Jira and Confluence can be "fast enough" in terms of enterprise software. Will this be web scale speeds? No. Does achieving web scale speeds provide value for 95% of users? No. The thing to do here is to improve integrations to reduce the amount of application switching that users are doing. For example, if you're a dev, use Smart Commits[1] to interact with your Jira issues as part of the commit message. No going into Jira or BB in the first place.
The editor in Confluence has been a work in progress in Cloud, but they're hitting a lot of issues. Part of the issue here is that providing an editor that is both friendly to an HR person, and to a dev is a complicated challenged. When Atlassian deprecated Markdown from Confluence, I was working for them at the time and published the Markdown Macro for Confluence [2] as a ShipIt project (internal hackathon). This has helped thousands of orgs interact with Confluence via Markdown. At the same time, we're building a Drag and Drop editor for Notification Emails in Jira, and holy moly are there a lot of edge cases and problems that we hit. There are entire businesses that do nothing other than sell make and sell editors. I wouldn't underestimate the complexity involved in this.
[1]: https://confluence.atlassian.com/bitbucket/use-smart-commits... [2]: https://marketplace.atlassian.com/apps/1211438/markdown-macr...