5 ms·

You are missing the point entirely. Any sufficiently complicated product will eventually have major CVEs, as you say. Anyone having hosted Atlassians product k

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.

shukantpal 5y ago
However, one does not conclude from the other as is insinuated in the comment.
- arghwhat 5y ago
  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.
  - aeternum 5y ago
    It follows in theory but may not in practice. Certain software may have lots of defects that are not CVEs.
    - arghwhat 5y ago
      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.
  - kruczek 5y ago
    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.
    - arghwhat 5y ago
      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.
samstave 5y ago
Where may I learn more about exactly how they are "garbage fires on the inside"? Thanks
- trhway 5y ago
  Try to use one
  - pixiemaster 5y ago
    Try using two of them connected together.
    - wizzwizz4 5y ago
      In order to do that, one would have to try to connect one to the other, which is usually sufficient.
- arghwhat 5y ago
  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...
  - brazzy 5y ago
    So... you do not, in fact, have an answer to the question?
    - arghwhat 5y ago
      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.
      - ashtonkem 5y ago
wiz21c 5y ago
> 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 :-))
- kodah 5y ago
  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.
- HillRat 5y ago
  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.
  - dwd 5y ago
    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/ https://fogbugz.com/evidence-based-scheduling/
    - jlarocco 5y ago
      > 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.
  - knightofmars 5y ago
    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.

shukantpal 5y ago

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

arghwhat 5y ago
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.
- aeternum 5y ago
  It follows in theory but may not in practice. Certain software may have lots of defects that are not CVEs.
  - arghwhat 5y ago
    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.
- kruczek 5y ago
  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.
  - arghwhat 5y ago
    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.

samstave 5y ago

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

trhway 5y ago
Try to use one
- pixiemaster 5y ago
  Try using two of them connected together.
  - wizzwizz4 5y ago
    In order to do that, one would have to try to connect one to the other, which is usually sufficient.
arghwhat 5y ago
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...
- brazzy 5y ago
  So... you do not, in fact, have an answer to the question?
  - arghwhat 5y ago
    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.
    - ashtonkem 5y ago

wiz21c 5y ago

> 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 :-))

kodah 5y ago
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.
HillRat 5y ago
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.
- dwd 5y ago
  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/ https://fogbugz.com/evidence-based-scheduling/
  - jlarocco 5y ago
    > 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.
- knightofmars 5y ago
  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.