3 ms·

Not being available on-prem continues to show how poorly Atlassian treats its enterprise customers. * No feature parity * No pre-built packages or support for

Not being available on-prem continues to show how poorly Atlassian treats its enterprise customers. * No feature parity * No pre-built packages or support for configuration / infrastructure management - everything must be packaged completely from scratch, without recommended package specifications or Dockerfiles etc. to build off of. Nope - "here's a tar.gz. Have fun!" * No proper enterprise support and no access to source code. We have a couple feature requests which are deep, burning desires which we'd love to either throw money or developers at but we can't because we have no relationship with Atlassian and we have no idea if Atlassian will ever address them because they don't publish product roadmaps. * Essential enterprise products like Crowd and Bamboo get short shrift and make it clear that communication inside Atlassian is lacking. Example: Bitbucket Data Center shipped with support to enforce GPG-signed commits. But because Crowd won't manage user GPG public keys, administrators can't revoke user keys without disabling access to Bitbucket entirely (so, GPG keys never get revoked), and Bamboo administrators can't enforce that project builds only use Bitbucket repositories with GPG-enforcement enabled, so for enterprises which actually need to enforce audit trails (for compliance, for building trust with deeply conservative customers...), the feature is worthless. Another example: Bamboo supports elastic build agents... but only on AWS. No support for vSphere, OpenStack, or heck any other public clouds like GCE or Azure. No Dockerized build agents for build jobs which don't themselves need Docker. Another example: Crowd is utterly lacking of any kind of investment. Sun Directory Server Enterprise Edition? Supported. OpenID Connect? 2FA? RSA SecurID? Yubikeys? lolnope. It finally got active-active clustering this year, though, so maybe that's a good sign? It's too bad their suite is in a class of its own because for all its faults, it's in a class of its own. Everything else sucks, one way or another.

jamiesonbecker 9y ago
Agreed - we offer on-premise (and drive significant revenue from it) at Userify for people who prefer their SSH key management in-house. To be fair to Atlassian, they basically invented on-prem with SaaS-style pricing (and did us all a great service), and their biggest competitor here (Slack) isn't available on-prem either. Some of these features that you list in Crowd are ironically very similar to missing features in our products, but we're actively working on them -- while not losing focus on being the fastest and easiest key manager to stand up. Running a software business can be challenging -- especially with a myriad of customer environments and feature requests. My feeling is that Atlassian got really big really fast and may have lost sight of their key differentiator -- which, to me, at the time, was pricing and simplicity. It looks like this new product might have brought back their flair on both counts.
- solatic 9y ago
  For what it's worth, I'd love to try and push Userify at my workplace, but without a trial version to install on-prem, I have nothing to try and persuade people of the value of Userify. Such a trial version should be relatively easy to push out the door - just disable Active Directory / LDAP integration in the trial version. Also, telling on-prem customers to run curl -# https://usrfy.io/upgrade.sh https://usrfy.io/upgrade.sh enterprise |sudo -sE to manually upgrade.... for a security product... completely DOA.
  - jamiesonbecker 9y ago
    Awesome, thanks! We definitely offer trial versions to install on-prem with a built-in permanent 10-server license (via a one-liner), and we provide 30 (and sometimes 60) day free trials for however many servers you need for anyone who asks. Converting to production is just a matter of pasting a new key. We could probably make this a bit more clear on our website though (it's buried in our docs section[1]) That is a good point and that doc page is really incomplete. Upgrades are completely automatic in Userify, and without diving too deep into the `curl https | sh` debate :), security conscious are always well advised to do the regular curl > file.sh anyway, even with CA cert checks. Just a good idea. 1. https://userify.com/docs/enterprise/installation/ https://userify.com/docs/enterprise/installation/
    - solatic 9y ago
      > without diving too deep into the `curl https | sh` debate :) So now that it's clear to me that it is possible to do an on-prem install, I decided to look at your curl->sh install script. You guys are basically justifying the fears of our security folks. After grabbing sudo from the user, without asking permission, you pkill NTPD (!), add pool.ntp.org (never mind that we may run our own NTP servers, specifically to remove Internet-based dependencies to lower risk...) and start NTPD again, invoke an install-pip script from a server you don't control (https://bootstrap.pypa.io/get-pip.py https://bootstrap.pypa.io/get-pip.py) without attempting to see if maybe there's a local package of pip available, and then install the EPEL repository. Which is, you know, a perfectly fine repository, but there's a reason why the software included in it isn't included with the official Red Hat repositories and so adding the EPEL repository without asking permission to do so can wreak serious havoc on servers with auto-update scripts installed with the intent to only grab security fixes for installed software. Why can't you guys just open-source some real packaging and respect the sysadmins who you want to be your customers? > Upgrades are completely automatic in Userify Most enterprises who are paying sysadmins to manage their server environments do so at least in part because they want their sysadmins to, you know, manage their server environments, like not upgrading services during peak usage (cough, Windows 10, cough). I'm not saying I won't still try out Userify... I'm saying that, when one of my chief complaints about Atlassian was a lack of packaging support, you came in to champion a product that not only doesn't provide packaging support, but reminds me why packaging support is necessary. If Userify meets our needs, we'll end up needing to package it internally, which means it has to go on our priority list somewhere, and probably not near the top. Sorry if this sounds harsh... just trying to keep it real.
compuguy 9y ago
That sums up my experience with Atlassian products that are self-hosted. They are essentially shooting themselves in the foot, especially with Customers that have to have the service run on site or on a air gapped network.

jamiesonbecker 9y ago

Agreed - we offer on-premise (and drive significant revenue from it) at Userify for people who prefer their SSH key management in-house. To be fair to Atlassian, they basically invented on-prem with SaaS-style pricing (and did us all a great service), and their biggest competitor here (Slack) isn't available on-prem either. Some of these features that you list in Crowd are ironically very similar to missing features in our products, but we're actively working on them -- while not losing focus on being the fastest and easiest key manager to stand up. Running a software business can be challenging -- especially with a myriad of customer environments and feature requests. My feeling is that Atlassian got really big really fast and may have lost sight of their key differentiator -- which, to me, at the time, was pricing and simplicity. It looks like this new product might have brought back their flair on both counts.

solatic 9y ago
For what it's worth, I'd love to try and push Userify at my workplace, but without a trial version to install on-prem, I have nothing to try and persuade people of the value of Userify. Such a trial version should be relatively easy to push out the door - just disable Active Directory / LDAP integration in the trial version. Also, telling on-prem customers to run curl -# https://usrfy.io/upgrade.sh https://usrfy.io/upgrade.sh enterprise |sudo -sE to manually upgrade.... for a security product... completely DOA.
- jamiesonbecker 9y ago
  Awesome, thanks! We definitely offer trial versions to install on-prem with a built-in permanent 10-server license (via a one-liner), and we provide 30 (and sometimes 60) day free trials for however many servers you need for anyone who asks. Converting to production is just a matter of pasting a new key. We could probably make this a bit more clear on our website though (it's buried in our docs section[1]) That is a good point and that doc page is really incomplete. Upgrades are completely automatic in Userify, and without diving too deep into the `curl https | sh` debate :), security conscious are always well advised to do the regular curl > file.sh anyway, even with CA cert checks. Just a good idea. 1. https://userify.com/docs/enterprise/installation/ https://userify.com/docs/enterprise/installation/
  - solatic 9y ago
    > without diving too deep into the `curl https | sh` debate :) So now that it's clear to me that it is possible to do an on-prem install, I decided to look at your curl->sh install script. You guys are basically justifying the fears of our security folks. After grabbing sudo from the user, without asking permission, you pkill NTPD (!), add pool.ntp.org (never mind that we may run our own NTP servers, specifically to remove Internet-based dependencies to lower risk...) and start NTPD again, invoke an install-pip script from a server you don't control (https://bootstrap.pypa.io/get-pip.py https://bootstrap.pypa.io/get-pip.py) without attempting to see if maybe there's a local package of pip available, and then install the EPEL repository. Which is, you know, a perfectly fine repository, but there's a reason why the software included in it isn't included with the official Red Hat repositories and so adding the EPEL repository without asking permission to do so can wreak serious havoc on servers with auto-update scripts installed with the intent to only grab security fixes for installed software. Why can't you guys just open-source some real packaging and respect the sysadmins who you want to be your customers? > Upgrades are completely automatic in Userify Most enterprises who are paying sysadmins to manage their server environments do so at least in part because they want their sysadmins to, you know, manage their server environments, like not upgrading services during peak usage (cough, Windows 10, cough). I'm not saying I won't still try out Userify... I'm saying that, when one of my chief complaints about Atlassian was a lack of packaging support, you came in to champion a product that not only doesn't provide packaging support, but reminds me why packaging support is necessary. If Userify meets our needs, we'll end up needing to package it internally, which means it has to go on our priority list somewhere, and probably not near the top. Sorry if this sounds harsh... just trying to keep it real.

compuguy 9y ago

That sums up my experience with Atlassian products that are self-hosted. They are essentially shooting themselves in the foot, especially with Customers that have to have the service run on site or on a air gapped network.