Atlassian Enables Default Data Collection to Train AI

Atlassian just goes from misstep to misstep. I still use their products quite often. The amount of P0 bugs I experience is absolutely crazy:

- Bitbucket workers are hopelessly out of date (self hosted). We've had to put so many random workarounds in especially for Docker, as they don't keep them up to date enough

- I have had a bug in JIRA for years where I can't reorder a new ticket unless I refresh the page

- Every new feature they introduce into JIRA/Bitbucket over the past couple of years just doesn't work.

- I tried their AI stuff on the free trial, didn't work at all, tried to cancel, can't cancel the free trial online and had to write a load of support tickets (of which the support ticket contact form bugged out multiple times).

Anyone have any insight into why things have got so so dysfunctional? Tech debt? Talent leaving? Both? Even 'bad' enterprise software tends to be able to keep the most basic features running, but Atlassian is a whole new category. If you check their 'community' it is just hundreds/thousands of bugs with workarounds.

AI contributing to rising natural stupidity.

I really wish I could find a better source to link to for this. By default, all free and paid customers are being opted-in to their data being used for AI training.

All your Confluence pages, Jira tickets, etc.

https://support.atlassian.com/security-and-access-policies/d... describes how to disable this, but it also appears that the setting to disable this doesn't exist (it's not visible on any of our instances).

Plenty of other companies enable this by default too, such as Github, Figma, Adobe, Vercel. I think it's fair to assume that if you ahve data stored within any company, they'll by default use it for training.

The opt-out-by-default pattern has been gradually normalizing in enterprise SaaS, but what makes this particularly egregious is the combination of two things: the data scope (not just metadata, but all in-app content per kevcampb's link) and the broken opt-out (the disabling setting not rendering on any instance).

One is a policy decision you can argue about. Both together suggest the friction is intentional.

The data residency point is worth flagging separately - a lot of enterprise buyers treat region-pinning as a privacy guarantee for everything in their contract. It was never that. Residency tells you where data is stored at rest, not who can access it for what purpose.

I am wondering why not just rsyncrypt the source code before pushing to the repo?

>rsyncrypto is a utility that encrypts a file (or a directory structure) in a way that ensures that local changes to the plain text file will result in local changes to the cipher text file. This, in turn, ensures that doing rsync to synchronize the encrypted files to another machine will have only a small impact on rsync's wire efficiency.

https://manpages.ubuntu.com/manpages/focal/man1/rsyncrypto.1...

If the rumours of an Anthropic acquisition are true, this makes a lot of sense. Anthropic are probably looking for a clean, high-signal dataset of metadata around business tasks that they can buy.

No wonder they wanted to stop supporting the Data Center versions for on prem.