5 ms·

Fogbugz seems to really be pushing their cloud stuff though, so I basically ruled it out instantly when I was researching options - it's unacceptable to have to

Fogbugz seems to really be pushing their cloud stuff though, so I basically ruled it out instantly when I was researching options - it's unacceptable to have to host our code and tracker off-premises on hardware we don't control. Whereas even a small team can run JIRA or GitLab on their own hardware for a very reasonable price.

slantyyz 10y ago
They still offer an on-premises version though. IIRC, their on-prem version price was fairly reasonable (that was almost 10y ago though)
- anildash 10y ago
  (I'm the CEO at Fog Creek.) We've updated the on-premise version of FogBugz to be completely in sync with the hosted version, so all the latest features are on both now.
  - problems 10y ago
    If you're willing to talk publicly, what's the pricing like for a very small, self-hosted group? I'm talking 3 normal users, might scale up to 5 or so. We're probably too small to be worth your time, but JIRA is offering $10/yr for up to 10 users, $10 more if you want the JIRA Agile features too.
    - anildash 10y ago
      Our pricing is here, you can check it out for yourself: http://www.fogcreek.com/fogbugz/pricing http://www.fogcreek.com/fogbugz/pricing In short: We cost a little bit more, but include features that are separate, add-on products for Jira, and generally software developers are a _lot_ happier using FogBugz. If you want to know more, just drop us a line; don't want to be too spammy here.
      - problems 10y ago
        Just want to confirm - those prices hold for the self-hosted "On Site" version too, where you don't have to provide any management of the data and hosting?
- deleted 10y ago
  [deleted]
jessaustin 10y ago
Unless there are regulatory constraints (can't expect logic there...), I don't understand this attitude. Are all your dev boxes air-gapped? If so, how do the devs use google, stack overflow, etc.? If not, how is your on-prem setup so very different than one that used SaaS?
- problems 10y ago
  The attitude is simple - don't give your code, and especially don't give access to your devops repositories to 3rd party companies who simply don't need it. If a security vulnerability happens on the public Fogzbugs instance, we'd be bitten by it badly in this sort of situation. In our setup, we protect against that by exposing the JIRA webserver and git servers only inside of our private network. It's not about perfect security, but it does greatly reduce the attack surface when the server isn't even accessible via the internet. I can't prevent anyone who wants to from signing up for the free trial of Fogzbugs and exploiting their publicly running system - even logged-in-only exploits are possible in such a case. Not to mention the issues with downtime on these cloud providers. My provider has had 1 sizeable, noticeable outage in the last 5 years. It spanned about 20 minutes. Look at a big, popular cloud service like GitHub - they've had several in the past year alone, spanning hours at times. I find these sorts of compromises where I'm offering my code and server configurations to a 3rd party company (where basically any admin there is free to read it, or anyone who can compromise their admins) to be rather poor. I'd rather keep the blame within my own company and be in control of our data fully rather than having to worry about whether Fogzbugs operations follows proper security precautions, I only have to worry about whether we do. Call it paranoid if you want, but I think it's a more than reasonable precaution to not just throw your data around to anyone who asks for it. Especially data which could lead to compromise of servers and customer information. I value my customer's information much more than I value any gains from some easy to use cloud service.
  - jessaustin 10y ago
    Thanks for the detailed reply. The downtime issue is certainly understandable. I hope you're keeping customer data out of DVCS, but it's true that flaws in your code might be more "discoverable" if an attacker had that code. It does introduce another step into the attack, however, to have to hack FogBugz before reading your code and discovering the flaw that hacks your services. You know your threat model better than we do, but I doubt most carders would bother with that...

slantyyz 10y ago

They still offer an on-premises version though. IIRC, their on-prem version price was fairly reasonable (that was almost 10y ago though)

anildash 10y ago
(I'm the CEO at Fog Creek.) We've updated the on-premise version of FogBugz to be completely in sync with the hosted version, so all the latest features are on both now.
- problems 10y ago
  If you're willing to talk publicly, what's the pricing like for a very small, self-hosted group? I'm talking 3 normal users, might scale up to 5 or so. We're probably too small to be worth your time, but JIRA is offering $10/yr for up to 10 users, $10 more if you want the JIRA Agile features too.
  - anildash 10y ago
    Our pricing is here, you can check it out for yourself: http://www.fogcreek.com/fogbugz/pricing http://www.fogcreek.com/fogbugz/pricing In short: We cost a little bit more, but include features that are separate, add-on products for Jira, and generally software developers are a _lot_ happier using FogBugz. If you want to know more, just drop us a line; don't want to be too spammy here.
    - problems 10y ago
      Just want to confirm - those prices hold for the self-hosted "On Site" version too, where you don't have to provide any management of the data and hosting?
deleted 10y ago
[deleted]

jessaustin 10y ago

Unless there are regulatory constraints (can't expect logic there...), I don't understand this attitude. Are all your dev boxes air-gapped? If so, how do the devs use google, stack overflow, etc.? If not, how is your on-prem setup so very different than one that used SaaS?

problems 10y ago
The attitude is simple - don't give your code, and especially don't give access to your devops repositories to 3rd party companies who simply don't need it. If a security vulnerability happens on the public Fogzbugs instance, we'd be bitten by it badly in this sort of situation. In our setup, we protect against that by exposing the JIRA webserver and git servers only inside of our private network. It's not about perfect security, but it does greatly reduce the attack surface when the server isn't even accessible via the internet. I can't prevent anyone who wants to from signing up for the free trial of Fogzbugs and exploiting their publicly running system - even logged-in-only exploits are possible in such a case. Not to mention the issues with downtime on these cloud providers. My provider has had 1 sizeable, noticeable outage in the last 5 years. It spanned about 20 minutes. Look at a big, popular cloud service like GitHub - they've had several in the past year alone, spanning hours at times. I find these sorts of compromises where I'm offering my code and server configurations to a 3rd party company (where basically any admin there is free to read it, or anyone who can compromise their admins) to be rather poor. I'd rather keep the blame within my own company and be in control of our data fully rather than having to worry about whether Fogzbugs operations follows proper security precautions, I only have to worry about whether we do. Call it paranoid if you want, but I think it's a more than reasonable precaution to not just throw your data around to anyone who asks for it. Especially data which could lead to compromise of servers and customer information. I value my customer's information much more than I value any gains from some easy to use cloud service.
- jessaustin 10y ago
  Thanks for the detailed reply. The downtime issue is certainly understandable. I hope you're keeping customer data out of DVCS, but it's true that flaws in your code might be more "discoverable" if an attacker had that code. It does introduce another step into the attack, however, to have to hack FogBugz before reading your code and discovering the flaw that hacks your services. You know your threat model better than we do, but I doubt most carders would bother with that...