Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Atlassian prepares to abandon on-prem server products

theregister.com

Post reply on HN
Print view View original

41–50 of 205 posts

Re: Atlassian prepares to abandon on-prem server products

#41

Post by wdfx »

preisschild wrote: post #37
kwanbix wrote: post #33

Earlier quoted context omitted.

While Jira does many many things right, it is also horrible in so many ways. What options are you evaluating?

Not OP, but we moved to Gitlab Issues. Project Managers are missing some features, but the devs (including me) like it a lot more due to integrating so well with PRs/commits.

The problem with this though, is that commonly a requirement (ticket) does not map exactly to a single code repository.

I feel that it is breaking encapsulation in a sense to be dealing with issues at the repo level. The repo and the code are implementation details of the business requirements. The tickets describing requirements belong at the next level up of abstraction?

Re: Atlassian prepares to abandon on-prem server products

#42

Post by wdfx »

RHSeeger wrote: post #25
consp wrote: post #16

Earlier quoted context omitted.

> as the features have expanded in capability Yet I still cannot import anything like in the old editor (e.g. markdown), adding images in lists was added two years after forcing switching to the new editor and you still cannot continue numbered lists in another item line and have to start over. Extensions exist to do this but these things should be standard in any editor.

The new editor in Jira is drives me nuts. They replaced a perfectly good, functional markdown editor with the current POS, and it causes me problems nearly every single day.

It constantly annoys me that even copy/paste in their editor does not work. I have to hard-reload the page to make it work again ... wtf.

Re: Atlassian prepares to abandon on-prem server products

#43

Post by peanball »

wdfx wrote: post #41
preisschild wrote: post #37

Earlier quoted context omitted.

Not OP, but we moved to Gitlab Issues. Project Managers are missing some features, but the devs (including me) like it a lot more due to integrating so well with PRs/commits.

The problem with this though, is that commonly a requirement (ticket) does not map exactly to a single code repository. I feel that it is breaking encapsulation in a sense to be dealing with issues at the repo level. The repo and the code are implementation details of the business requirements. The tickets describing requirements belong at the next level up of abstraction?

There are issues at group / org level in GitLab that can span such tasks.

Re: Atlassian prepares to abandon on-prem server products

#45

Post by Mandatum »

kylecordes wrote: post #31
blibble wrote: post #27

no amount of complaints from... everyone about jira/confluence being absurdly slow or horrible to use had any effect on my employer (large multinational) but their decision to abandon on-prem has resulted in the company migrating away from all atlassian products the best thing atlassian have ever done!

But they're not abandoning on-premise, though one could get that impression from the tone of the article. They are only dropping the small-business targeted Server tier, they are keeping the enterprise targeted Datacenter tier. It's pretty much a drop-in replacement, with extra capabilities. And annual payment instead of initial+upgrades payment.

DC is deprecated unless you’re FedRAMP (which they still haven’t got). Good luck getting that if you’re not F500.

Once they get the government tick off approval they’ll kill off hosted versions completely.

Last I heard they hired some guy to help with their FedRAMP certification, then got found out for blackmailing his previous employer (I guess HR didn’t Google him during hiring): https://www.bleepingcomputer.com/news/security/it-worker-jai...

Re: Atlassian prepares to abandon on-prem server products

#46

Post by viraptor »

maccard wrote: post #34
ChatGTP wrote: post #30

Earlier quoted context omitted.

Atlassian stuggles with editors like no other company I've seen. I don't remember the last time I had a problem with an editor except for using any Atlassian product. Not sure what the fuck they do, but they really seem to have trouble with this aspect of their products. Which is ironic because their products are essentially CRUD products with a heavy emphasis on data entry. Like, if anything out their products needs…

I think it's related to how atlassian develops their products - they acquire then. Jira, confluence and Trello have three different editors because they're three different products developed by three different companies.

And yet, they are trying to move Trello to the terrible rich text editor like Confluence. So far you can still opt out and send a "wtf are you doing?" feedback about the new editor, but I'm not sure how long that will last.

Re: Atlassian prepares to abandon on-prem server products

#47

Post by cbzbc »

Is this actually news? This seems to refer to something they did a while back, and is being repeated on the occasion of the deadline being 5 months away, rather than anything new being announced by Atlassian.

FWIW my place swallowed the DC charge for now, on the basis that we'd explore our options and possibly shift away.

Re: Atlassian prepares to abandon on-prem server products

#48

Post by mrweasel »

botulidze wrote: post #19

The problem with Jira is that we don't have many alternatives at enterprise level. Maybe for smaller teams ( I had a lot of hopes for Github Issues [0] but since they announced the product on last year's Universe event, there were not many news. Maybe this November they will come back with an update. At this point, I feel Jira is like WordPress. It maybe slow and overbloated, but you can have absolutely any plugin an…

It's really hard to find any product or suite of products that replaces Atlassians offerings. Sure you can easily find a issue tracker product, but can it be a service desk at the same time? Bitbucket, Confluence and Jira also integrates really really well. You can have entire workflows that just makes sense, link to documentation, pull-requests/commits and tickets. I've frequently used this setup in a ITIL environment, entire workflows where you have tickets for test, staging and production deployments, the production deployment is a ticket that have the relevant pull-requests linked and the documentation is automatically updated because everything works together.

There's a number of companies offering "Jira replacements" at it's either just service desk features or a ticketing system, almost as if the authors never really used a full-blown Jira (/Atlassian) setup.

People complain a lot about the UI and speed of Atlassians products, but on-prem isn't really slow, even with a ton of plugins, but you do need trained staff to manage it. The UI is because of Jira doesn't really impose much in the way of restrictions on how to use it. You can basically mix and match anyway you like, service desk tickets mixed in with SCRUM workflows... doesn't mean you should, but you can.

Re: Atlassian prepares to abandon on-prem server products

#49

Post by solarkraft »

throwawaaarrgh wrote: post #14
steveBK123 wrote: post #11

Jira/Confluence are two products that have gotten markedly slower and slower over time and as they've moved into the cloud. I observe load times that remind me of the 90s sometimes using their cloud apps. Incredible they are killing on-prem, but maybe it makes it harder to compare to the slow as molasses cloud offering that way?

I have the opposite experience; many if not most of the features have gotten faster as the features have expanded in capability

Same. On-prem at my last employer was super slow. Cloud is wildly fast.

Re: Atlassian prepares to abandon on-prem server products

#50

Post by [deleted] »

wdfx wrote: post #41
preisschild wrote: post #37

Earlier quoted context omitted.

Not OP, but we moved to Gitlab Issues. Project Managers are missing some features, but the devs (including me) like it a lot more due to integrating so well with PRs/commits.

The problem with this though, is that commonly a requirement (ticket) does not map exactly to a single code repository. I feel that it is breaking encapsulation in a sense to be dealing with issues at the repo level. The repo and the code are implementation details of the business requirements. The tickets describing requirements belong at the next level up of abstraction?

[deleted]
Post reply on HN