This is a fair question, you shouldn't be downvoted. Lean ticket trackers and productivity tools are perennially launched and invariably become as bloated as the incumbents.

This is because the information in these tools is business critical and needs to be consumed by almost everyone in the company. Moreover, different people need access to the same information in different forms of presentation, with aggregation and emphasis of different data. In contrast it's easy to make a work tracker just for developers - GitHub and GitLab have pretty much solved that problem. Making a ticket tracker which works as a single source of truth for all members of an organization who need access to the tickets is much more difficult.

Developers, PMs, VPs, support staff, data scientists and designers all need access to overlapping information which is ideally stored in the form of tickets. But each of those roles needs something different from the tickets, both individually and in aggregate. You can't just target a single group here, because then you're trying to get the company to adopt separate repositories of work (it's already an additional complexity that work is split between e.g. GitHub and Jira, for example).

So to obtain the critical mass of adoption they need for product market fit and growth, these tools organically evolve to become everything to everyone in an organization. And suddenly your tracking tool is stuffed with metrics, integrations, feeds, dashboards, reports, etc.

The other thing is that these tools become especially bloated by integrations and plugins. A brand new instance of any tracker or project manager feels clean and fast. A few years in, it feels slower and more crowded by all the custom/third party additions rolled into it.

> Developers, PMs, VPs, support staff, data scientists and designers all need access to overlapping information which is ideally stored in the form of tickets. But each of those roles needs something different from the tickets, both individually and in aggregate.

I realize this would be a lot of work, but I would be really interested to see some examples of "the ticket the developers want", "the ticket the VPs want", "the ticket the designers want", etc.

Role based UI can be the answer.

Yeah, that would be the modern solution. As far as I can tell even Salesforce has tried that with role-specific views that are customizable. But somehow it just converges back to everyone having everything all over again, but this time with 8 different frontend views to be maintained.

I've worked on these sort of problems, and I can guess why.

What happens is that a new field gets added, and whoever's adding it claims it's really "important" and needs to be seen by everyone. It'll invariably set as mandatory to be filled in too.

2 years later and some integration breaks because the integration doesn't set that field and you end up looking at that really important field and every single project has it set to exactly the same value.

Repeat ad nauseum.

The other thing I've seen a few times is when assessments or a bonus depends on some field so they make it visible to everyone. Then the bonus scheme changes, but they never hide the fields that no-one cares about any more.

> when assessments or a bonus depends on some field

Ugh, this reminds me of a mess I inadvertently participated in..

A certain employee, on an unrelated team to mine, decided to to go down the route of becoming an agile/scrum master/evangical and somehow got "reduce instances of X" as their personal KPI/development goal one year. Soon after this, they're pinging myself and other team leads on slack whenever X field is filled out on JIRA and demanding justification. Eventually because of this harassment I just stop filling out the field, leaving it as the default value and just verbally communicating the fact to whomever needed to know. Later on I find out that I wasn't the only one that took this route,And guess what happened next! The scrum master is promoted to a management position, in part due to their stellar KPIs! Excellent work all around!

Someone has to pay for complexity. Let that be vendor and it’s engineering. Rather end users.

Scaling is only half of it. There is a lot more to Jira than just CRUD over a few entities. It's trying to be issue tracking and project management rolled into one. For example:

- Workflows

- Access control over fields

- Custom fields

- Release management

- 3P plugins and integrations

- API access

I am far from being a fan of Jira but they do have a rather large set of features. Every time I evaluate the hottest new issue tracking and/or project management solution, there is something lacking as compared to Jira.

I've often half-joked that the road to JIRA is paved with other project management tools and ticketing systems.

I don't think anybody really sets out with the intent of using the one reputedly cumbersome tool that can do anything - but after growth and pivots and new requirements and new teams and special workflows... you end up needing a combination of features that is literally impossible to get with any other tool, and who wants to fracture into multiple tools?

So you get JIRA. And it just does it all, and even if nobody is overjoyed, nobody feels like they lost, either. There's value in that.

https://restya.com/core-jira-slack-alternative seems to have covered all these area. (I'm on their beta program)

Got it, thanks.

JIRA offers an almost limitless amount of customization to fit any workflow. I think the custom attributes/fields/reporting part of it adds a lot of complexity.

Yeah... and once it comes down to a company's pm level, they all lock it down to what they think is the best, leaving teams using something that is guided towards PM and reporting, instead of getting job done.

Got it, thanks.