Atlassian Cloud ToS section 3.3(I) prohibits discussing performance issues

I'm curious, I'm a Cloud customer and I can tell you that the service is incredibly slow even for a small scale setup (2 Jira Projects and 3 Confluence Workspaces). There's an insane amount of network requests seemingly for mouse tracking. By telling everyone here, that Atlassian Cloud products are insufferably slow, am I violating the ToS?

I was actually thinking about doing a write up on the issues I've had but this seems to make me think I should do so AFTER I find someplace else to go. Right now GitHub is the likely destination but would love to hear other suggestions.

The comment right next to yours is a link to cloudflare's TOS with the exact same provision. It is not just Atlassian and Oracle.

"Atlassian Cloud ToS section 3.3(I) prohibits discussing performance issues" - Their ToS may prohibit it, but that is in no way going to stop me from doing it - I don't give a shit about some document they write. Atlassian products suck hard and their performance characteristics are horrible. I hate being forced to use their crap at work.

Sorry to hear it's been a frustrating experience. I'm a PM for Confluence Cloud and we're always trying to make it better. Would you be willing to share more specifics, such as: - Pages with content X are the slowest - Trying to do A/B/C is annoyingly slow - etc ?

(edit: looks like HN is severely limiting my reply rate so apologies for delays)

We're trying to focus on frustrating pages/experiences rather than number of network calls and such, because while the latter is correlated, the former (frustrating slow experiences) is really the bar and the higher priority.

In terms of the ToS I'm not from legal so can't say (still looking into it), but have definitely had conversations with users on public forums about performance issues, and afaik no one has been accused of violating their ToS.

(edit: since I can't reply due to HN limits I'll try to add some stuff in this edit)

------- @plorkyeran "target things that are easier to fix than those with highest impact" -> this is a good point and something we're trying to do. Engineers know the former (easier to fix) pretty readily, but identifying "highest impact" requires some work, so I'm (as a PM) always trying to find out. It's of course some combination of these two (low hanging fruit, high impact items) that forms the priority list.

------ @igetspam (moved followup into a reply to trigger notification)

------@core-questions "perf to take over company for 6mo-1yr" I'm not in the position to make that level of decisions, but can certainly pass the feedback up the chain. The perf team is trying their best though, so any info anyone can provide us can help us apply our resources in the right place

That explains the stance but is not sufficient to justify it. It gives Atlassian infinite power to stomp on any benchmark that shows poor performance under a claim that it is flawed. It is also irrelevant that it's been in your ToS since 2012: Precedent or longevity do not make consumer-unfriendly restrictions acceptable.

This is implicitly recognized by allowing internal assessment: That assessment would be just as vulnerable to flawed methodology and therefore flawed decision making on products. If you were that concerned over such issues, you could issue further restrictions on performance assessment that limited such activity to be conducted only under Atlassian's close review or using your own mandated methodology. One reason you probably don't do that is because potential buyers would balk at those restrictions and either pass on your product or responsibly engage in due diligence and perform their own assessments regardless.

Further, the resources to do extensive internal assessment may be lacking in many organizations, which means your provision to allow internal testing is meaningless to many customers. As a result, the prohibition against public disclosure thereby deprives them of any way of obtaining objective external analysis.

You could satisfy your concerns by requiring that public disclosure be reviewed by Atlassian prior to publication. You could require an option for Atlassian to comment on the results with embedded notations without restricting publication itself. That would still be heavy handed but at least allow a reasonable amount of independent review of your performance.