For me that’s exactly the problem with JIRA. Each team I’ve worked with uses a different board, workflow, and what not. I still don’t understand the hierarchy.

And since it is infinitely configurable, the UX is just horrible. It’s not optimised for any particular audience and is all over the place.

For me this is a huge benefit: the engineering team, product management team, qa team, ux team, etc. can each see the things that are relevant to them in the way that they like while still being able to pass the tasks off to the other teams / track them if they would like. You have to put in work to make each flow work for each customer & make sure that the tags are standardized, but once thats in place its super easy (at least for my team)

My reading of this is: software development is still such a disorganized activity that the industry considers it acceptable for each organization to simply make up their own system. Jira is built to work for any such system, no matter how crazy, and your particular instance can change completely at any time (like if your manager reads the wrong blog post over lunch).

This does not make me feel any better about Jira. It's like those videos of early attempts at flight, and Jira is bragging that they make flapping wings and spinning wings and triplane wings and bird-shaped wings -- whatever you want! Great for their company, not so great for me.

My experience is that they can sort of see, the things that are sort of relevant to them.

Jira is the definition of a jack of all trades, but master of none.

> "it is far and away the most customizable and powerful PM software I have used"

Opinionated software is good. Unlimited customizability is bad and the source of almost all of Jira's problems.

Not really. Opinionated software is good when the opinion is something you agree with. When you need the opinionated software to something it wasn't designed for it's frequently really bad.

CMake is opinionated. It's built assuming that the build yields an executable file for Windows, Linux or Mac. Try getting CMake to cross-compile for more than one platform at the same time, or build not than one executable and then build a root filesystem into a system image. This is impossible without circumventing CMake entirely. It's actually pretty easy in Make, which is what CMake generates.

There are tons of organizations which need to manage their projects in a way Trello or Pivotal aren't designed for. These tools require you to adopt a methodology and they work great as long as you do. But if you need to do something strange like integrate with a separate system test team, good luck. That's really why organizations adopt JIRA. They want to do things that the tool designers thought you should never do. And those things are necessary in the eyes of those organizations.

Being opinionated is great if you're a human, but the best software is built by people who are trying to help me do my job, not by people who want to dictate how it should be done from the perspective of not being my employer.

Everything you state as being a "benefit" of Jira's customizability is why devs hate it. The software's features aren't being used to help developers do their jobs, which was the original reason for the product, but to help managers and report fetishists collect reams of unnecessary data points. It is a hindrance to your organization, but at least you get to make sure all those checkboxes are checked.

It sounds like you're either one of the report generators, so it's awesome for you, but all your devs hate it.

Probably the source of almost all of their sales too.

Sane defaults are good, customisation for those that want it are also good. A single way of doing things, good for those it works for.

Can you give some examples of its power and customizability? What does JIRA do that for example Trac can't?

(Trac can often be customized with 10 lines of simple Python (or CSS, HTML, JS) dropped as a single file into the plugin folder and you're done. It's the hacker's bug tracker. And it's fast and quite easy to use. I wonder why it's not more popular anymore.)

I've never used Trac for tickets. My first introduction to Jira was replacing 5 different in-house ticketing systems covering systems, desktop support, to software development. Here are some of the things I've noticed that I haven't seen other ticketing systems do as well; each department's tickets had their own fields that were unique to them, you could pass a ticket department-to-department with a clear interface to map and update fields, a clear history was preserved when going from department to department, you could have a simplified interface for users (with additional, more intimidating fields for people working the tickets), you could update tickets by replying to emails (seems obvious/trivial, but that feature is often missing), search was very good. This was close to 10 years ago.

Fiddling with Trac tickets right now it seems like something I would love if I spent the time to learn. For example, search is just a text field. I imagine if I learned the syntax it'd be very powerful. I remember Jira, at the time, had a "simple search" with separate auto-completing fields for things like opened-by, assigned-to, open-date, and "complex search" that used a text-based syntax.

Not that Jira was amazing, but UI makes a big difference. A coworker showed me a different frontend someone had built in front of BugZilla and it looked 100x more approachable.

After working at places that didn't use Jira (well, almost all of them evaluated it but deemed it too expensive and too large of a project to migrate) my current job uses Jira, again. Man is it slow (I've heard this is growing pains of converting a codebase designed to run on a single server and making "services" out of it to scale) and there's way more confusing integration. I've been trying to use it as little as possible.

https://gitlab.com/surfsara/email2trac allows updating Trac tickets from email replies. (I have not used it, but I know it's actively maintained.)

The default Trac search is very simple, sometimes maybe too simple. There's also the Ticket Query UI for field-based searching, which I use very often and quite like. Plugins for using solr or whoosh search engines also exist, but I haven't used them and don't know much about them.

I also recommend the auto-completion plugin: https://trac-hacks.org/wiki/WikiAutoCompletePlugin

I've been using it for over a year now and still get lost in navigation and fail to understand the hierarchy.

One time I tried to put the effort to learn it but gave up pretty quickly.

What does all this customization worth if only a small fraction of the users can successfully use it ?

There's literally one person in the company who has mastered it. Everyone else just get by with it.