Hacker News Reader

Comment by cogman10 | Hacker News Reader

> why don't you think some other company has come along and toppled the Jira crown?

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.

I don't buy that it's a matter of competitors not being better. It is more about inertia.

The argument you have here could equally be applied to C++ or Cobol "Why is new code being written in these languages? Why is C++ so popular even when there are many other competitors? Certainly tons of languages have tried."

I currently work in a field that is disrupting existing products that were, no joke, written in the 90s in VB6. It can be super hard to sell our product to a lot of people, not because our product isn't better, but because they've been using our VB6 competitor since the 90s.

View on HN

I disagree with this. Absolutely, once Jira (or any particular project management tool) gets it's "tentacles" into a sizable enterprise, it's very difficult to dislodge.

But I've seen tons of other examples in my career of companies making larger, more difficult transitions because they clearly felt the risk/benefit was worth it: moving from CVS/Subversion to git, moving from on-prem to the cloud, moving from Windows to Mac, moving from hipchat to Slack, moving from Oracle to postgres, yada yada yada.

I'm certainly not saying it's easy, but I fully believe that if a project management solution came along and all stakeholders went "holy shit, this is so much better than Jira", that many companies would make the switch. This hasn't happened, and honestly if you hear people complain about Fogbugz or Asana or whatever that it's probably an equal "per-capita" bitch rate.

I think it's maybe a bit of both? I worked at an org that was using Trac for most things. It's probably fine for a small, engineering-driven company, but it's not very full-featured and isn't great for PMs and other business types.

So once the company got large enough, management wanted to switch. Many of us essentially said, "ok, that's fine, but please please please not Jira". And yet, they went and hired some consultants who were like "oh, Jira is the industry standard for your line of work, you'd be taking on a huge risk not using it, blah blah blah". Management bought it, and they've been on Jira ever since.

If you said "please please please not Jira", what other options did y'all suggest that you thought would be better?

> moving from CVS/Subversion to git

Was that really painful? We did that transition and it amounted to having teams one by one run the "git-svn" script on their repos to port over to git. Even with over a million commits on our central SVN server, the whole process generally took around 5 minutes per project. Even in the worst cases, it was something like 1 hour.

The most painful part we had was putting a rate limiter in place to keep our SVN server from toppling over.

> moving from on-prem to the cloud, moving from Windows to Mac, moving from hipchat to Slack, moving from Oracle to postgres

These are certainly all more difficult but also things that aren't central to the way the company operates AND can be done a piece at a time. Moving from Jira->something else can't really be done in a piecemeal fashion.

The other big problem here is Jira has a wider audience than just the dev department. Dev saying "Let's go from svn to git" is something that doesn't hardly need involvement from the C levels. They never (usually) touch or look at the VCS interface. In fact, the only thing you listed that I think would be a hard sell to C levels is switching from windows to mac. Though, I suspect a lot of them are using macs anyways. Try getting your C levels to agree to switch from mac or windows to linux and I bet that'd never fly in any organization.

> I fully believe that if a project management solution came along and all stakeholders went "holy shit, this is so much better than Jira"

I just disagree. The best counter example is Internet Explorer. Both Firefox and Chromium have been better than IE for a long time (10->15 years). So why didn't every corporation switch to Firefox? Why did Chrome end up winning for desktop web browser even though it came so much later (2008)?

The answer is simple, chrome advertised on media that stakeholders watched.

Chrome eventually won, but it got there through deep pockets and advertising. If there's anything that will topple atlassian, it will have to be through the same route. That product/product set has to be better AND they have to spend a lot of capital advertising so that other shareholders find out they exist. Without doing both those things, toppling atlassian will be a long nearly impossible slog.

It depends upon how SVN is used, and for the team I'm on, it's going to be painful. SVN allows you to checkout a subdirectory of any given repository, and because of our history, we have everything my team writes (10 programs) in two repositories, with a lot of sharing between the two repos. This is something that is ... not easy ... to replicate with git [1].

As far as Macs go, the company I worked for was 50/50 Mac/Windows, with the majority (if not outright all) of the developers using Macs. We got bought out, and our new corporate overlords were purely Windows, and didn't know what to do about our Macs. Personally, I ended up with a fully manged Windows laptop that I never used [2] for three years before I could send it back and send me a "semi-managed" Mac laptop.

As for Jira, eh. I didn't mind it that much, except when management mandated that every team use the same queue for everything. That queue didn't match our preferred method of working, so we kept our old queue purely for internal stuff. Our time tracking system is way worse than Jira by far.

[1] Not to say I love SVN---I hate it actually, and would prefer to use git. But having used SVN for over a decade on these two repos, and given their structure, it's going to be interesting.

[2] Except to turn it on to have it autoupdate when I got "the email". What a colossal waste of resources. My team kept on using the Macs.

Jira's core positioning is huge companies with complex organizations that will be willing to adjust tooling to their needs. Sure small and middle size companies can be happy with it too, but they're far from being the main profit center.

At that level, there isn't much competition. It costs a lot to develop a product that does everything and throws in the kitchen sink. It doesn't make sense for a startup, Open Source project could fit the bill (bugzilla ?) but they'd still need a service providing company, probably some corporate backing for the contracts etc.

Basically, JIRA is the Microsoft (or Oracle?) of the field, and any other company wanting to fight that turf would need incredibly deep pockets with an upfront investment that would only be recouped way way down the line, if they ever make it that far, and fighting JIRA would mean lower margins than if they dominated the market alone. Overall that doesn't look like a sane bet in any shape or form.

> It is more about inertia.

Can't agree more. A few years ago, I joined a large healthcare organization to take a break from the startup grind. During my tenure, I witnessed the selection process of an issue tracking system and a chat platform.

They picked Teams for chat even though Slack ruled, and Teams was way behind in features. Why? Because it was the easy choice. They had the typical Microsoft stack just like every other large company, so go with Teams even though it sucked.

They picked Jira for issue tracking. Why? Because it was the easy choice. No one knew how to fully leverage it, and there was no way workflows would get buy in across the whole organization.

In large companies, especially non-tech ones, tooling decisions are driven more by laziness and CYA than what's the superior product.

Here's a better answer to that question:

Crowns don't come from inherent value. They come from monarchy.

Jira holds the crown because so many are convinced the "industry" in which it leads is worthy or valuable.

What value does a monarch provide? Order. Structure. Authority. Corporate environments value these because - art its core - that is what "Corporation" is: a new system of governance.

Most of the complaints about Jira can be turned to Corporatism itself.

The new Thomas Jeffer(y)son? ;-)

>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.

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

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.

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.

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... 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.

We start new companies all the time and nothing has been able to replace JIRA past the 5-10 engineers who know exactly what they are supposed to do stage.

It isn't that surprising that a programming language has inertia, it has lots of 'mass' so to speak -- programmers have to specialize in the language, and an ecosystem of libraries has to be built. It is more surprising to me that an issue tracker like Jira does. Surely people aren't specialized in... Jira-ing or whatever.

> Surely people aren't specialized in... Jira-ing or whatever.

There are people who build their careers on this. Their are consultants who do this, and only this. And the unfortunate reality is, Jira is so complicated, there actually is a reason for these people to exist.

> And the unfortunate reality is, Jira is so complicated, there actually is a reason for these people to exist.

So, easy benchmark for when something has become too complicated to be worthwhile: An industry of consultants is making a living off it.

SAP consultants, Oracle consultants, JIRA consultants... You don't see very many Excel consultants, do you? (Whaddoino, maybe there are.)

You get a few projects in JIRA…and you’re stuck. Then you add JIRA Service Desk or Service Management or whatever the hell it’s called these days…and you’re stuck. Then you add some Confluence docs linked to your tickets…

Unless one is really willing to throw institutional knowledge out, changing tracking systems is extremely costly.

You mean as hard as when Git obliterated every other VCS within the span of a few years? If products are better, they get adopted. How do you think every single company in the world started to develop for iOS between 2008 and 2010? When the upside is obvious and the path to transition is well-defined, there is very little friction.

I still don't understand how git won the source control battle so decisively. I respect git for what it's good at and its power, but from what I've observed it's far from clearly being the obvious choice of source control for closed source software shops. JIRA I can take or leave, it does the job - it's hard to imagine anyone being driven to hate it, but I can believe having it badly configured would be a serious drain on productivity.

I can only speak to the comparison with hg, but for large repos, git's performance is literally 10x better in our case (we have two parallel copies, one in hg and one in git, so as to smooth the transition to git). hg seems more usable, but certain decisions are poor (e.g. baking the branch name into each commit); overall I have no strong preference between the two except for the speed.

But the speed pretty much drowns out any other signal.

git's performance increase came around at the right time, too. Code bases were becoming bigger and bigger, and Agile's popularity preached a lot of branching. SVN branches were a full copy, making things way worse.

Yeah that had occurred to me. But I'd used TFS (which didn't have light-weight branches) with Agile-like development practices and it wasn't that big a deal. Maybe if the codebase was 10 or 20 times bigger it would've been.

Migration was easy, it was decentralised, had a famous original author & a huge famous project using it and had a lot of "hip" source code platforms such as github, gitorious, bitbucket (pre-atlassian) and gitlab.

I'm not surprised it won tbh.

Game companies are still using Perforce though.

> Game companies are still using Perforce though.

Maybe the ratio of text to non-text assets?

That, and repo size can get huge in a game project and no one wants to have to copy the whole thing to do a check out. Svn still sees use for gamedevs that don't want to buy.

> I respect git for what it's good at and its power, but from what I've observed it's far from clearly being the obvious choice of source control for closed source software shops.

At this point git is the incumbent, which is self-sustaining: developers already know git, so you'd need a really compelling reason to use anything else and take on the burden of training your developers to use it.

It helps that git is freely available and is by far the top choice for Free and Open Source projects.

Of course, SVN used to be in the same position, but git is such a great improvement that it was able to win out. I imagine git's origins in Linux kernel development may also have been a factor in its early success.

> You mean as hard as when Git obliterated every other VCS within the span of a few years

There's not a concept impedance mismatch going from CVS->SVN->GIT. The concepts are so similar that git-svn exists to convert a SVN repo into a git repo (and a similar conversion tool exists for CVS->SVN)

Jira is so flexible and configurable that no such tool could exist. Migrating to a new tracking system requires that you either lose all currently tracked issues and their history OR you spend the money and effort handcrafting for your org a Jira->Foo translator to preserve some semblance of history. The larger and more diverse the org, the harder such a tool will be to craft.

> How do you think every single company in the world started to develop for iOS between 2008 and 2010?

Because ignoring a company that commands 30% of the market is a bad idea? How do you explain the flop of WebOS which was, IMO, a far better UX and OS compared to either IOS or Android?

How about when every single company rewrote their frontend stack in React after angular.js was done, circa 2015? Or when everyone moved to k8s within 2 years around 2017-2019? Hell, now even companies that definitely wouldn't benefit from anything related to k8s are diving into it.

What I am trying to show by these examples is that things can move fast, very fast, and that in our industry there are no such thing as well-entrenched tools. Yarn got adopted within a year above npm, the "default node package manager". Everything is always up for grabs, if you can show the benefits, however small they are. And the history aspect of Jira isn't an unsolvable problem, pretty much every single issue tracker in the world offers a Jira import, and losing issue history is far less damaging than it was losing "commit" history when everyone was moving to git back in the days. If a company can show that their alternative to Jira solves a percentage of common complaints against Jira, while offering the same capabilities of scaling that Jira does, people will follow. Nobody wants to deal with crappy products. Especially since the ones suffering the most from Jira are usually the ones in charge of setting up the very processes that Jira is supposed to help with, and to procure the tooling.

> How about when every single company rewrote their frontend stack in React

God I wish that were the case. My company is still rocking Angular unfortunately :(

> Or when everyone moved to k8s within 2 years around 2017-2019

That did not happen. k8s got a good share of the market, but it's far from "everyone moved".

> What I am trying to show by these examples is that things can move fast, very fast, and that in our industry there are no such thing as well-entrenched tools.

The tools you are listing are all dev tools picked, used, and curated by development. Jira isn't a dev tool, it's a product management tool. There's a major difference between tools that devs can pick and choose and tools that an organization gets to pick and choose.

Even with your "yarn" example, while it took over it didn't replace "npmjs" as the centralized repository server. Just like gradle still gets it's artifacts primarily from maven central.

I'll go back to something I said elsewhere. If it's so easy to move and change why is C++ still being written? Why does it remain one of the most popular programming languages even though most people are VERY quick to point out it's major flaws. Even though other better alternatives exist (Rust, Nim, D, etc).

> losing issue history is far less damaging than it was losing "commit" history when everyone was moving to git back in the days.

Assuming you like everyone else went from svn->git I don't see how you'd have lost commit history. I personally converted a BUNCH of repos to git and didn't see any cases of lost history.

> I'll go back to something I said elsewhere. If it's so easy to move and change why is C++ still being written?

Because C++ is very very much a living and, most importantly, evolving language. It gives modern conveniences, while benefiting from existing user base and maturity. Alternatives may be better for specific emerging use cases but can’t just yet challenge the incumbent for the reasons above. One day C++ may have to yield, but at the moment it’s been actively renewed and the effort to migrate codebases to a new standard is smaller than porting onto entirely new language.

Migrating very large SVN repos to Git is far from trivial.

> embedded into the core of how a company works.

Doubtful. Unless you are working for a shitty company in the first place, bad tools essentially just get skipped and disused by autonomous teams and none of this matters. If the company 'embeds' a product in place of a workflow, that's not something a product is ever going to fix, that's an organisational problem.

Reply on news.ycombinator.com