Hacker News Reader

Comment by hn_throwaway_99 | Hacker News Reader

> The good thing about the fact that Atlassian offers both on-prem and cloud versions of their offerings is, everyone is now aware of the awful engineering practices that underpin their products.

Regardless of what one thinks about Atlassian, this is a completely ridiculous bullshit statement, and anyone who works in the world of business software knows it.

I don't think there is a company out there that hasn't had critical CVEs, nor most major open source projects, either.

Microsoft had a recent vulnerability in their Azure Cosmos DB product that left thousands of customers' data unprotected. Google has released multiple patches to Chrome in the past month.

If you demand you'll only use products from companies or open source projects that have never had a major CVE, you'll be writing a lot of your own software that probably has even worse security.

View on HN

You are missing the point entirely.

Any sufficiently complicated product will eventually have major CVEs, as you say. Anyone having hosted Atlassians product know that these products are nothing but garbage fires on the inside, as the commenter above said.

Both of these statements are true and not mutually exclusive in any way.

However, one does not conclude from the other as is insinuated in the comment.

If all products have CVEs, and CVEs are a form of defect, then it follows quite naturally that highly defective products will have CVEs, likely more than less defective products.

So yes. Yes it does. Unless you meant that CVEs imply garbage code, in which case I think you read the comment wrong.

It follows in theory but may not in practice. Certain software may have lots of defects that are not CVEs.

All products will have defects that are not CVEs, hopefully by a large margin.

But every sufficiently complicated product will have defects of this type, and a higher probability of defects does increase the probability of CVEs.

So, it follows in practice, as can be seen by looking at CVE rates from projects with high defect rates (web browsers, kernels, ...) vs projects with low defect rate.

Note that defect rate differences can be caused by multiple things.

But here we're talking about one particular CVE:

> everyone is now aware of the awful engineering practices that underpin their products

This one fault doesn't tell anything about overall quality of the product.

This is a complete misunderstanding caused by not readinf the first half of the first sentence of the comment.

The full sentence:

> The good thing about the fact that Atlassian offers both on-prem and cloud versions of their offerings is, everyone is now aware of the awful engineering practices that underpin their products.

I.e., because the software is available for on-prem deployment, we have experience deploying, managing and debugging it, and therefore know that it is garbage, and we can apply this knowledge to conclude that their cloud offering is garbage.

It does not say the product is garbage because of a CVE.

Where may I learn more about exactly how they are "garbage fires on the inside"?

Thanks

Try to use one

Try using two of them connected together.

In order to do that, one would have to try to connect one to the other, which is usually sufficient.

First you need a fire starter, which in this case must be made out of bills valued 100 USD each or greater. It'll take quite a few to light the Datacenter licenses that are the now the only on-prem tier on fire...

So... you do not, in fact, have an answer to the question?

Lacking humor I see.

My point is that it is experience acquired from managing these for a decade. If you wish to acquire this experience you need to run it, which is now even costlier than it used to be.

Actually using these products suffices. Especially confluence, which regularly reduces me to a stream of particularly foul profanity.

Atlaskit (their UI framework) is open source.

It is very enlightening. Try using their editor component to display the text of one of your Jira comments and making it display attachments.

find or create an installation and examine how the database is put together

> these products are nothing but garbage fires

Would you care to give us alternatives, for example, to the JIRA bug tracker (which I used a lot, slowly :-))

ZenHub! I love, as an engineer, that it layers on top of GitHub issues. So, in my general day to day I never leave GitHub.com or GHE, while project managers get all their shiny toys in ZenHub that plays nicely with GitHub issues.

Spolsky’s FogBugz is still out there after a few ownership changes, and is still a hell of a lot less painful to use than Jira.

It was innovative 13 years ago, but never really caught on.

Kiln was also a great product and allowed for using both Git and Mercurial. It was way better than anything else at the time, but lost out to Github.

I always liked Spolsky's Evidence Based Scheduling that was built into the products.

https://fogbugz.com/evidence-based-scheduling/

> Kiln was also a great product and allowed for using both Git and Mercurial. It was way better than anything else at the time, but lost out to Github.

I used both FogBugz and Kiln at a previous employer, and I really liked FogBugz, but we had nothing but problems with Kiln. We had a fairly large team (maybe 75-100 people) and a good sized project (maybe 300k lines), and it was painfully slow to do anything in Kiln and it was down/broken at least once a month. It wasn't so bad early on when we were small, but it didn't scale with us very well.

No. It isn't. Having recently moved (a year ago) from FogBugz to Jira it's like a fresh breeze has blown into our case management process.

Is TFS no longer considered a competitor? Feels like it should have been the first mentioned here. Not saying TFS is problem-free, of course.

Azure DevOps?

I've had to use Azure DevOps recently, and it made me long for the speed, simplicity, and stability of Jira...

The most annoying bug was that one could only have around 4-5 tabs open before something went wrong and everything stopped updating.

> Would you care to give us alternatives, for example, to the JIRA bug tracker

Paper.

An Excel spreadsheet shared on a Windows for Workgroups share drive.

Carrier pigeon.

Quitting software to become a llama herder.

Seriously, though, after over two decades of using different tracking systems I think that the real alternative to stuff like Jira is to not go there. You may think that you need all those bells and whistles, but you really don't. What you actually need is the simplest possible issue tracking system you can get away with. All you really need is a prioritised list of issues, and a list of who is working on which issues now. ‘Kanban’ boards get pretty close.

Minimalism is power.

I don't disagree that Atlassian programs are generally bloated, but it is interesting to see everyone jumping at JIRA when its Confluence with the CVE...

JIRA is too many things to too many people - in the quest to be everyone's bug tracker, they wrote (badly) in the whole kitchen sink. This is a general issue with most software, though. Especially big software.

You cannot have complex capable software that is also simple. That's an oxymoron. You can have complex software which works, but it is difficult to get there, and keep it there. There is simply too much that can go wrong that over time, it almost must go wrong.

Keeping everything 'simple' is not an alternative - the world is complex and so even a bunch of simple things, when put together, make something complex. Think unix shell scripts which can be so much sphagetti. The unix philosophy is to keep things simple, and yet ignoring the complexity leads to its own complexity.

That's the real 'terrible engineeing practices' which get down Atlassian and everyone else's programs.

Someone said 'use paper' or 'quit and become a llamma herder' - these seem simple but again, paper burns, shepherds get shot or held up by drug gangs.

All to say, I don't think JIRA is actually that bad. There could be worse products, there could be better. But it would exceedingly difficult to make something simple which also served everybody.

I would prefer to use anything but JIRA,I fucking loathe it.

Pivotal Tracker. I've found it to be a much more productive tool, and teams using it typically move alot faster and are far happier than those using Jira.

Jetbrains Youtrack is soooo much better in any and all ways that I can think of. https://www.jetbrains.com/youtrack/

I don’t disagree with what you’re saying about software having ongoing vulnerability issues. But, that’s exactly what the problem is with communications-centric solutions that don’t offer strong data security protections such as end-to-end encryption: you’re always one CVE away from having your company’s data exposed. And, in this specific case, there is a MAJOR difference between Chrome getting owned, and the program that hosts all of a company’s internal communications concerning, among other things, known vulnerabilities in their software.

Think about that for a second. If someone finds a vulnerability in JIRA, they don’t just find a vulnerability in that software: they’ve got access to support tickets, issue tracking, etc about lots of vulnerabilities in lots of software. That’s a big deal.

The fact that the US government had to step in and say PLEASE TAKE THIS SERIOUSLY, rather than Atlassian going into a Code Red situation, shows that they just don’t take the level of responsibility they’ve been given as seriously as is required for what they’re doing. This isn’t just some lousy app having a CVE. This is the keys to the kingdom for a lot of very critical software. This is systemic risk. The problem isn’t the code, it’s the culture.

If you “work in the world of business software” and you think that’s a “complete bullshit statement,” I really hope you don’t work on anything for which such systemic risk is possible. Because, to turn your statement back on you, that’s a complete bullshit way to treat the responsibility you have for the data with which you’ve been trusted. Go build a social media app or an online shopping site or something, and stay out of critical systems that can create cascading vulnerabilities.

> and stay out of critical systems that can create cascading vulnerabilities

Oh, you mean like Microsoft and Google in the examples I gave?

Why are you changing the goal posts? Your original statement was that this issue is evidence that "everyone is now aware of the awful engineering practices that underpin their products." My clear argument is that this is not the case, as lots of companies with systemically critical software also have bugs of this magnitude, or more.

Much as I hate everything Atlassian touches (although Portfolio was pretty useful as a stand-alone tool if you kept it far away from JIRA), It’s not like MS Office or Sharepoint have never had vulnerabilities..

Eh? If there was a remote root exploit in Chrome, ALL your data is similarly 0wned, exfiltrated, and for sale to your enemies. EVERY computer you have used Chrome on has is now suspect, and all website data each of those compuers to will now have its data stolen and sold on hackers.ru and .ch. All my employer's business data being stolen is one thing, but all of my online banking credentials are of particular personal interest to me in staying confidential.

For people who have the Atlassian Cloud offering this is not a problem and has been fixed. The only people who are impacted are the one who host Confluence themselves. There isn't much that Atlassian can do except that tell them to update the software.

If you are maintaining the software of someone else and this software is exposed to the internet that's your responsibility to update the software. If you want your service to be available from the web and have good security, use the cloud offering, that's what it's for.

And if you don't want to use external software to manage your internal knowledge, then create some shared windows folders that nobody use and quickly becomes a mess. What alternative do your propose ?

Oh, serendipitously, the article currently directly below this one on HN is "Apple iMessage Zero-Click Hacks". So add Apple to the list of companies on your "awful engineering practices" list.

> don’t offer strong data security protections such as end-to-end encryption

Imagine being so naive as to think that documentation would be improved by e2e encryption. It's not bad enough convincing developers to write things down, now we need to explicitly share those things with every new person who joins the team?

"Sorry, we can't fix your bug for 6 weeks, Bob's on paternity and the fix is documented on his page".

> MAJOR difference between Chrome getting owned, and the program that hosts all of a company’s internal communications

There's at best 0 difference between these things. Pop chrome, harvest tokens, access Jira. Think about that for a second. What critical company information is not accessible to someone who has arbitrary code execution in your browser.

> awful engineering practices that underpin their products

Confluence has become an absolutely disgusting, bloated Javascript beast. The amount of JS that it loads is unbelievable.

Atlassian has a reputation for poor engineering/backend practices. It's a great (to use) product though.

Interestingly I assumed (due to personal and anecdotal experience fro colleagues) it’s not a good experience and that was part of what the parent was referring to.

Coming from ClearQuest, Jira was a breathe of fresh air some years ago. We can run projects with several hundred to thousand people with it (the on prem version) without problems and UX is ok IMHO. Maybe it's easy to screw up the config?

It's slow, but so long as you don't do anything “out of the ordinary” (i.e. try to act like the average sort of person who would use Jira), it's decent enough to use. I've personally had no workflow issues, though I could tell there was something deeply wrong with the internals.

Then again, if you're only using the “ordinary” features, Jira doesn't have much advantage over any other bug tracker; Gitea can integrate with Jira just as well as with any other bug tracker, and well enough that the Jira / Confluence integration isn't necessary.

The Atlassian softwares are okay, but (from my limited experience) worse than their alternatives. On several occasions, I expected a bug, but it refreshed or redirected, and there wasn't a bug. I have found no bugs while using Jira, and not unusably many while using Confluence… but I can say the same for Gitea, GitHub, Gitlab and even Bugzilla. (Gitea's native issue tracker is actually good enough – and therefore better than Jira – for everything I ever used Jira for.)

> Jira doesn't have much advantage over any other bug tracker

Ohhh found the non power Jira user! Gitea is good enough for your org. Without knowing your requirements this is pretty much a blanket statement. Gitea is nowhere near good enough for a large engineering org.

Example: groovy integration with Jira allows an enterprise to build their own custom workflows. Like integrating with your Vcs to enforce funded work (requiring an open Jira issue in git commits). Features like this, until recently, left them in a league of their own. GitHub Actions has leveled that playing field. Gitlab and gitea can fight it out with bugzilla, but you won’t find them in most engineering orgs.

Another example: building out complex dev roadmaps ahead of time with constraints and relationships. Bridging the gap between dev, product, and project management

> Not trying to dig on your usage of issue tracking

> but you won’t find them in any worthwile engineering org.

sure.

Examples?

It's an ok product until you run into performance issues. Which due to said horrible backend engineering is numerous. Also their support is awful.

Don’t worry, the datacenter edition takes only 200ms to load their HTML, and then another 15s to generate their JS package on every single page load.

I don't remember a company like whatsapp having this kind of problems.

Just FYI, the grammatically correct phrase would be "these kinds of problems" when plural versus "this kind of problem" when singular.

(note that this is not a complete list) CVE-2021-24026 CVE-2021-24027 CVE-2020-1891 CVE-2020-1909 CVE-2019-11933

Perhaps you should consider that not knowing a thing is very, very different than that thing not being true...

I can see how you jumped to the conclusion this CVE means Atlassian is nonsense, but it’s not the only take on the comment. The discussion arising from a

I’m not really sure what the point of the rant is. It’s not as if such a comment conclusion is as big of deal to reality as an idiot staying unvaccinated.

But I get it; someone is “wrong”* on the internet.

* where wrong is defined very specifically to one or a handful of particular readers but the error doesn’t rise to being a real problem for humanity

Reply on news.ycombinator.com