[dsr_]

Can I self-host it?

The only reason we're going to move away from JIRA is that Atlassian dropped server installs and is moving everyone to their cloud or datacenter products.

Have a great conversion from JIRA and a reasonably-priced self-hosted option, we'll be looking at you in six months.

[syed99]

Its definitely something we've been exploring when putting our product roadmap together. I'm curious though, if we had a private cloud instance vs self hosted? I'd love to understand why self hosted would be the option you'd go for.

[dsr_]

Our security policy doesn't let us put confidential information into other people's hands unless they are willing to commit to the full value of damages from a breach on their side.

It's a great question to differentiate sales critters: the new ones are sure that they can work something out; the middle ones are dubious; the experienced people chuckle and disengage politely.

[andy_ppp]

Are any external suppliers stupid enough to agree to this? Isn’t it basically writing you an unlimited cheque if someone hosting your data gets hacked?

[dspillett]

I suppose some might reason that if something that serious happens they'll be out of business anyway, and just make sure the responsibility can't follow them if it does happen and the business does fall.

Those that specialise in holding other party's data like this will have liability insurance to cover significant events financially (though there is of course still reputational risk to consider) and processes in place to try make sure such events don't happen so calling on that insurance never needs to happen.

> if someone hosting your data gets hacked

It wouldn't be if any someone got hacked, just if something they are responsible for fails and enables a data leak, so they are not accepting third-party risk unless they themselves involve third parties in the mix. Proving you are not the source of a leak could be an interesting proposition though.

[firebird84]

This is actually a fairly big deal in enterprise sales. I learned that one of the reasons my company didn't use Slack and opted for a larger company's (arguably inferior) clone was that Slack was basically not suable (blood from a stone and all that). My company basically wanted the ability to hold the provider liable for a breach. I look around at our other vendors and most of them appear to be capable of weathering a lawsuit, whereas Slack (at that time) was not. Now...however....things have changed. :)

[Terretta]

Every supplier to regulated industries is smart enough to do this, as it’s generally required.

[andy_ppp]

I suppose you need to charge a lot more to provide such guarantees.

[chipsa]

You find how much their data is worth, then take insurance out to cover it, and pass the cost along.

[sjogress]

I think for most/many European companies, especially those that are potentially handling PII, there are regulatory concerns with using US based hosting/companies.

My employer for instance has put a ban on deploying anything new on AWS/Azure/Google Cloud until legal issues have been settled after Privacy Shield was invalidated.

Everything new right now needs to be on EU/EFTA data centers run by EU/EFTA companies. This essentially means self hosting since most clouds are owned by US companies.

[shagie]

A lot of orgs have various regulatory constraints. For much of public sector, you're either going to need to be able to have it hosted on AWS GovCloud or allow the organization to self host it on their own servers.

[syed99]

Thanks for the clarification, there’s definitely a pathway for us to allow for this in the near future. I think it’s a safer path than running after industry specific compliances.

[robertlagrant]

Working in a regulated industry, shipping (e.g.) some docker images and a Helm chart is definitely preferable!

[superMutex]

In our case it's due to regulations in place. For example, our data must stay on Canadian servers at all times.

[syed99]

Makes a lot more sense now, the flexibility to configure to your own resources for regulatory reasons.

[tyingq]

You'll probably also encounter people who are a bit jaded after their experience with Jira's hosted cloud versus on-prem. Jira on-prem can be slow also, but at least you can throw ridiculous amounts of hardware at it and make it okay-ish.

[syed99]

We had a horrendous experience with on-prem during my last tenure. A lot of it came from lack of support and performance improvements. Atlassian has its way to strong arm it’s biggest customers into paying more or throwing in sub processors in the mix. At some point we had IT, Dev Ops and Engineering consultants trying to get our workflows running.

Eventually we caved and pushed their account execs to support a “secure” private cloud that passed our IT teams compliance criteria. Fun times!

[lanbanger]

Can you define what data has to remain on Canadian servers? If it's just user data, and not your actual code, then you could use a synthetic data provider like https://synthesized.io to convert real user data to synthetic with similar properties, then host your code wherever you want.

[joshuaissac]

Jira tickets (and Tara tickets) are going to have user data (including poorly-defined user requirements). Turning that into synthetic data with Synthesised will almost definitely lead to developers building software that does not match the original requirements.

[lanbanger]

If you have real user data in non-production systems (e.g., development JIRA/tracking system) you're already doing it wrong. At the firm I work at we scan all non-prod systems for user identifying data and flag it up for removal.

[prpl]

datacenter is an on-prem product though?

[detaro]

Sure, at absolutely stupid price increases especially for smaller orgs. It starts at $42,000 a year... Also known as 840$ per user if you have 50 users.

[danpalmer]

That's $70 a month, which seems high, but not extortionate given that it's meeting very specific requirements.

[detaro]

The very specific requirement of doing exactly the same thing you could do for a fraction of the price the year earlier: manage issues? Running software is not some exotic requirement.

[danpalmer]

> Running software is not some exotic requirement.

But running software in an environment you don't control, but where it's expected to run perfectly or else you're on the hook for the support, that is. On-prem services are hard to get right, there's all sorts of issues around things like upgrades, software versions, etc.

I get that it used to do this, but software gets updated and moves on. I think it's reasonable to expect that you can remain on an outdated version and old pricing scheme, but give up support after some period of time, but I could also understand companies not wanting to offer that.

[OJFord]

The on-prem requirement; probably most paying users with that requirement are not very price sensitive, since it's a regulatory requirement on them, or similar. They're also probably typically large orgs (so it doesn't look so expensive per user, if they would even consider it in those terms), and resistant to switching providers due to other requirements/processes anyway.

[detaro]

I choose the 50 users example for a reason: I know plenty companies in that kind of size that prefer self-hosting and are looking to replace Jira now.