3 ms·

>Because it's really hard to kill off the market leader when the market leader is embedded into the core of how a company works. eh. I've experienced a number

by bragr 4y ago

>Because it's really hard to kill off the market leader when the market leader is embedded into the core of how a company works. eh. I've experienced a number of painful tool and platform shifts in my career that basically came down to "it's cheaper" so I don't buy that companies are unwilling. If someone provides the feature set that is some combination of cheaper and better, then the only thing you really need is a migration path (Jira import tool in this case), and you'll be able to make some sales. Make enough sales and you start looking popular and that can provide its own inertia. The fact that this has not happened is, to me, evidence that nobody has done it better so far.

cogman10 4y ago
> Jira import tool This is the problem. Jira is so highly configurable that without recreating a good chuck of the Jira feature set, an "import" tool will be pretty hard to make. Any competitor in this marketspace will have to invest a considerable amount of their time creating and maintaining such a tool, which I imagine if they ever became a serious contender, Atlassian would put up some anti-competitive road blocks. (For example, forcing everyone into their cloud offering so they can more easily control endpoint access....)
- shagie 4y ago
  I'll note that most other competitors that are engineer (rather than management) focused don't use a jira workflow approach and instead tend to be more of an adhoc "apply labels" and "we trust you to apply the correct labels". The Jira complex state table tends to be something that isn't replicated as its part of the "we're not Jira" value proposition.
  - cogman10 4y ago
    I don't disagree, but just to point out the issue with transitioning, even in a basic sense, is that Jira allows and can invisibly create new states for pretty critical pieces. Your case might be in a "Closed" state on the UX, but internally that can be "custom state 48083232" because some wingus decided to first start by naming it "to be closed" and then changed it to just "Closed". That can be different for every project. This is why an import tool is a complex thing to figure out. You have to translate all the potential custom states into the "we're not Jira"'s states that make sense.
    - shagie 4y ago
      Yea... I wrote a redmine to Jira importer. That was... interesting. I'm familiar with Redmine and its table structure. I was able to reverse engineer the json schemas (there are examples at https://support.atlassian.com/jira-cloud-administration/docs/import-data-from-json/ https://support.atlassian.com/jira-cloud-administration/docs... but little in the way of actual schemas and DTOs to work from) and successfully imported everything including a number of custom fields in Redmine and comments and attachments. The only "oops" part of the Great Import was that the users that were in Redmine but not in Jira (people who left the org and thus were never imported into Jira) had entries created as the sysadmin who ran the import.

by bragr 4y ago

cogman10 4y ago

> Jira import tool This is the problem. Jira is so highly configurable that without recreating a good chuck of the Jira feature set, an "import" tool will be pretty hard to make. Any competitor in this marketspace will have to invest a considerable amount of their time creating and maintaining such a tool, which I imagine if they ever became a serious contender, Atlassian would put up some anti-competitive road blocks. (For example, forcing everyone into their cloud offering so they can more easily control endpoint access....)

shagie 4y ago
I'll note that most other competitors that are engineer (rather than management) focused don't use a jira workflow approach and instead tend to be more of an adhoc "apply labels" and "we trust you to apply the correct labels". The Jira complex state table tends to be something that isn't replicated as its part of the "we're not Jira" value proposition.
- cogman10 4y ago
  I don't disagree, but just to point out the issue with transitioning, even in a basic sense, is that Jira allows and can invisibly create new states for pretty critical pieces. Your case might be in a "Closed" state on the UX, but internally that can be "custom state 48083232" because some wingus decided to first start by naming it "to be closed" and then changed it to just "Closed". That can be different for every project. This is why an import tool is a complex thing to figure out. You have to translate all the potential custom states into the "we're not Jira"'s states that make sense.
  - shagie 4y ago
    Yea... I wrote a redmine to Jira importer. That was... interesting. I'm familiar with Redmine and its table structure. I was able to reverse engineer the json schemas (there are examples at https://support.atlassian.com/jira-cloud-administration/docs/import-data-from-json/ https://support.atlassian.com/jira-cloud-administration/docs... but little in the way of actual schemas and DTOs to work from) and successfully imported everything including a number of custom fields in Redmine and comments and attachments. The only "oops" part of the Great Import was that the users that were in Redmine but not in Jira (people who left the org and thus were never imported into Jira) had entries created as the sysadmin who ran the import.