But Jira is not cloud-only?

https://www.atlassian.com/enterprise/data-center

In any case it was clear it's not for small shops like us.

That said, air-gapped is a hefty requirement, so perhaps those customers are predominantly large?

There are lots of very small classified networks out there with only a few dozen users.

There are a lot more user communities course that aren’t necessarily airgapped, but where they have special compliance requirements that pretty much mandate self hosting (or at least bring-your-own cloud.)

We do the similar with our B2B product (in an entirely different niche). We have everything from single-person companies up to very large ones. Similarly we set price based on use-case and requirements.

$51k for the smallest license they offer.

I still run an old version on an air gapped network and will continue to do so until we're forced to change for some reason. It's not a hefty requirement; we run it for a team of < 10 developers on a small VM and it just works.

To be more specific, they killed off the legacy Jira Server and now only offer these enterprise versions of Jira and the rest of the suite if you won't move to the cloud.

I like the cloud for a lot of reasons. But, making your software worse to make your stock price higher seems like a loser for everyone long term.

Same experience with JIRA. I read all these negative comments here and elsewhere about how slow and clunky JIRA was, and I couldn't relate at all.

Then I realized all those who complained was using JIRA Cloud and we were using on-prem, and it all made sense.

We've since moved to JIRA Cloud ourselves, and I understand now.

We moved and none of the new places had any viable computer room, so literally had to put the rack in a closet And well, that ain't cutting it for physical access control these days. Thankfully we have very simple flows without any BS, so not too many 1-5 second clicks to get things done.

I have to load half a dozen tabs of new tickets and then cycle through them triaging and defining fields in a collated manner to make it so my time isn't hugely dominated by waiting.

We used to have on-prem and it was probably about an order of magnitude better, but still nowhere near "XP in a VM accessing a site on localhost" level snappy.

Usually with these tools, the performance problems magically vanish if you disable all the integrations people have set up. My company is constantly denial of service attacking Jira with Github updates, for example.

Edit: typo

It worked great in volume testing in our environment. Their IT department installed it on high end servers (hundreds of cores, incredibly expensive storage subsystems, etc) but users complained of latency, random slowness, etc. IT spent weeks investigating and swore up and down it wasn't their end and must be a software issue. We replicated and completely sanitized production volumes of data to try and recreate locally and couldn't.

Finally I flew down and hosted their entire infrastructure off my laptop for a day (I'll skip all the security safeguards, contract assurances, secure wipes, etc). It flew like a thoroughbread at a racetrack. No latency, instant responsiveness, no timeouts, no hiccups. Their entire staff raved about the difference. The results gave the business unit VP what she needed to bypass the usual, convoluted channels, and someone must have lit a fire under their IT VP - by the end of that day their internal techs identified a misconfiguration on their storage arrays and solved the problem. I can only guess how many other apps were silently suffering for weeks or months on the same array. I joked I'd be happy to sell them a laptop or two for a fraction of their mainframe cost.

Self-DOSing is exactly what it was.

Also big enough corps give underpowered machines to the mass of employees (anyone not a dev, designer or lead of something) so latency is just life to them.

Even Atlassian doesn't use Jira cloud. Btw it's not "JIRA".

1. Unless major customers are actively closing their accounts due to the poor performance, improving performance isn't a priority.

2. The people who pay for it aren't the people who use it, so the performance can get very, very bad before customers start closing their accounts.

JIRA stands for JIRA Isn't Really Awesome.

That would explain a lot.

> Btw it's not "JIRA".

When did they change this? I'm fairly certain[1] it used to be JIRA.

[1]: https://confluence.atlassian.com/jira061

Jira on-prem was dog slow, yes, especially if it didn't live on the same server as the database. But Jira Cloud? It isn't much faster than that! It's a piece of hot mess. Loading placeholders everywhere. Really I have absolutely zero idea what Atlassian is doing, but I know for sure optimizing for performance is not amongst the things they are doing.

The dialogues and context menus took forever to show and page navigation was beyond painful.

We had dedicated engineering for maintaining our Jira and Bitbucket, and they still fell over. We eventually moved back to GitHub. (Our usage went from GitHub on-prem pre-MS -> Bitbucket on-prem -> GitHub cloud post-MS.)

I hate Jira regardless of where it's deployed. It's a beast.

Well except Bamboo. It’s terrible

Sometimes it feels like Jira is so incredibly configurable but is really missing the "pit of success". There is a way to make it nice to use and reasonably performant, but you really need to go into it with a strong plan. And even then it's really easy to balls it all up in short order if you're not vigilant.

The annoying part is the amount of garbage fixes in JIRA's UI. For example, because of the loading speed, and me losing patience with it, if I don't wait for the page to finally finish loading and click on the "create" button, then instead of the modal dialog for issue creation, I get a whole new page for issue creation. Both options are atrocious from UX perspective (because usually I need to copy text from the issue I was reading into the issue I'm creating), but at least when it's a modal window, I can pop open the developer tools and delete the modal part that prevents me from copying the text from the issue otherwise blocked from interaction.

Also, it looks like due to speed, some queries simply don't finish on time, and randomly, searches don't find all the issues they should. Especially searches that ask for "s.t. parent issue has such-and-such properties".

Ultimately, JIRA isn't built to scale (ironically, since it's written in Java, which was always defended as being slow for small problems but scaled well). The code has a lot of assumptions about some operations being fast enough to not require buffering / incremental implementation. And sometimes you hit the combos of such unoptimized operations and have to wait minutes for the program to respond.

Out of the box it is pretty generic. When I learned what it could actually do, it revealed itself as a sponge that can uniquely absorb complexity. Having someone familiar with JIRA show the ropes went a long way.

Some of these new development tools are pretty nice though. Variety is good, especially with the changes from Pivotal Tracker, etc going away.

On-prem is great if everyone is coming into the office, but I think orgs should pay more attention to the "remote experience" of their on-prem tools.

Notion, take notes

Feds are DMCA immune, so no real recourse.

Usually you do have recourse via procurement channels and reps. If you file a complaint with that agency stating that they’re using a license without paying for it, it will result in at least an investigation.

I wouldn't. I'd hire some Peter Gibbons type, who only does about 15 minutes of real, actual work in a typical week. Then I'd tell them they can finish early if all their pending cases are closed.

https://arstechnica.com/tech-policy/2008/08/air-force-cracks...

And unpaid software licenses are a violation.

Now maybe the client in this case may have had some kind if ownership clause, etc. but in general, procurement people tend to be pretty neutral in my experience.

Then again, over only dealt with small contracts (< $500k)

We have had companies outright refuse to even give us a price when we told them we wanted to investigate buying a license. Such a PITA.

Hopefully this was fixed, but this was the standing precedent at the time.

> probably be much cheaper than building and maintaining an air-gapped licence solution

I think this is an unwise attitude to take. There's something to be said for a simple picket fence. Even though someone could easily hop it if they wanted to, they lose plausible deniability and in most cases that's all that really matters at the end of the day.

This is the least surprising thing I’ve read all day.

- it is not at all surprising that when you remove cruft, code performs batter

- it is not at all surprising that this is not common enough amongst software engineers to even consider these things (competing business interests probably cause this often)

Seems like engineers forget to test these things nowadays.

I’m more surprised to hear that bug still hasn’t been fixed. Luckily I don’t use Windows myself since many years ago.

Some developers' judgement about needed dependencies can be suspect though: https://news.ycombinator.com/item?id=29241943

(presumably read in Adam Something's voice)

Can't we just read this as "there are 2 wins here: security and performance"?

Which is not surprising, but still a GoodThing(TM) right?