Shutting Down JAC (jira.atlassian.com)

[#1]

Or rather, should Atlassian shut down JAC (as we know it)? 

Hear me out... 

For more than two decades, Atlassian’s public Jira instance (JAC) has been the place to log requests, report bugs, and follow along publicly.

Early on, it worked: an open channel to talk to customers, gather feedback, and show progress. Over time, JAC grew from a helpful conversation space into something teams couldn’t realistically keep up with: 10,000+ requests, slow or no updates, and frustrated customers when their issue sat for months without news.

The intention was right. The constraint is capacity.

“Be open” is easy to say. “Put everything out in the open” doesn’t scale. A system that implicitly promises updates on every request breaks as soon as you outgrow it

If I were at Atlassian today, I’d shut down the public issue tracker. Here’s why... and what I’d do instead.

 

What it looked like day to day

I worked across various product teams at Atlassian for 15 years. In the early days of Confluence, JAC worked great. Same on Stash. But as the number of suggestions grew, we struggled to keep pace.

At some point we had a goal to update the top 50 requests every quarter. Sounds reasonable in theory. But it was still very time consuming.

At one point, we had a dedicated PM spent half their week in JAC, often just to say there wasn’t anything new. Customers didn't love it, and that’s time better spent on the actual work in play.

“Why hasn’t there been an update?” – lots of customers

The honest answer: the math doesn’t work. Even if you only update the top 10% of 10,000 requests (1,000) once a quarter, and each update takes 15 minutes, that’s 15,000 minutes—250 hours. At 8-hour days, that’s ~31 person-days every quarter. For status updates.

 

How to openly communicate at scale

Open communication at scale needs a tighter public surface.

A public idea board works when you can stay on top of it. At scale, it breaks. You can still be open. Just be open about the work you intend to consider or build.

1. Time‑boxed visibility
   Publish only the requests and ideas you intend to consider or build in the next 6–12 months. Capture everything else, but don’t list it publicly. The public surface should reflect the real planning horizon, not an infinite queue.
2. Engagement where it matters
   For published items, invite feedback, share trade‑offs, and provide progress updates. Keep threads alive with context: the problem you’re solving, constraints you’re navigating, and where you’re heading next.
3. Team‑originated ideas
   Don’t just mirror inbound requests. Share the team’s exploration and concepts early—before code. Ask for feedback on problem framing and approach, not just a running feature wishlist.
4. Replace voting with Wishlists
   Instead of public voting, use a “Wishlist” that limits the number of wishes per customer. Prioritization beats groupthink. You’ll get a sharper signal without turning feedback into a popularity contest.
5. Capture feedback (all of it)
   Feedback is a gift. Capture as much as you can. Ensure the product team responds to every single note—even if it’s just “Thank you!” Acknowledge the input; don’t promise action where none exists.
6. Track demand internally
   For ideas not publicly listed, connect inbound feedback to internal ideas and track demand. Keep the accounting inside; keep the conversation outside focused on what’s actually in play.

What this changes for customers and teams

• Customers see fewer public items, but get better context and more frequent updates on work that’s truly being considered or built.
• Teams spend less time maintaining a giant queue and more time engaging deeply where it matters.
• Product managers learn faster from targeted conversations, not a mountain of +1s.

Open company

“Open company” doesn’t mean “publish everything”

It means being clear about what’s planned, why it’s planned, and inviting feedback on those plans. Keep the conversation focused on the work that’s actually happening.

Fewer public ideas. More customer engagement. Better outcomes.

What do you think, does JAC need a revamp? Let me know in the comments 👇

Build what matters

If you’re rethinking how you share plans, gather feedback, and publish updates, that’s exactly what we built Released for: roadmaps, portals, and changelogs that engage customers without creating a public backlog you can’t maintain.

Take a look at our public roadmap or try Released on the Atlassian marketplace.

[Alex Koxaras -Relational-]

Hey @Jens Schumacher - Released_so 

I really can't say that I agree with you. I really like JAC and the fact that Atlassian doesn't try to hide anything. A few years ago, Atlassian was letting puny human to raise suggestions, but unfortunately that was deprived of us (but I can understand why it took that from us). I like the fact that I can search for a bug or a suggestion and guide my clients accordignly.

Atlassian has already a roadmap which is pretty decent https://www.atlassian.com/roadmap/cloud (and I'm sure you are aware of it).

In conclusion, I like JAC and I wouldn't want Atlassian to shut it down. :) 

[Jens Schumacher - Released_so]

@Alex Koxaras -Relational-  thanks for sharing your perspective.

I'm curious, how does it help you or your clients if a suggestion is publicly listed, but is never even looked at by anyone at Atlassian because it's one of 10,000 ideas? 

Take for example this ticket: 

https://jira.atlassian.com/browse/JRACLOUD-7320?filter=124546

The ticket was raised in 2005. Just today someone asked for an update. I bet that nobody will respond and that the ticket will still be open in 2030. 

And to be clear, I don't think it's a problem for most customers to have JAC, aside from being disappointed that their favorite feature hasn't been implemented. 

But it is a problem for Atlassian. Having tickets open for 20 years is a bad look, even though it's inevitable. Every company has those. They just don't have them published for everyone to see. 

[Rustem Shiriiazdanov _Actonic_]

Although I find it so entertaining to browse through the jungle of old tickets (It gives me a perfect vibe of treasure hunter/archaeologist journey), I agree with @Jens Schumacher - Released_so. JAC does not fit it's initial purpose anymore. 

[Jens Schumacher - Released_so]

That's my point @Rustem Shiriiazdanov _Actonic_, JAC does no longer serve the intended purpose. 

At the same time, I am curious if anyone is still getting value out of having JAC. 

[Alex Koxaras -Relational-]

@Jens Schumacher - Released_so first of all I can find a solid answer, that this specific bug/suggestion exists and it is in progress, and/or will never be fixed (plenty of tickets date back to 2005, no question about it). So in that sense I'm direct and honest with my client and he can decide for himself the next steps (e.g. try and buy a 3rd part app, or just live with this bug, or even consider switcing platforms, if that is that big of a deal for him). What good would be for me or my client, if that information was "withheld" from us?

Atlassian is doing pretty much what you are doing with your app, but it has not granted us any Software license to view the kanban board :)

To be honest, perhaps maybe Atlassian needs to move from JAC to JPD.

[Tim Eddelbüttel]

JAC must be keep alive! @Jens Schumacher - Released_so, you as a former Atlassian employee might have more insight how it's treated internally.

The problem of "what should we develop first" isn't a JAC problem. Any idea box solution (incl. your own product) will get these problems if you get two many requests.

JAC isn't only about feature requests, it's also about great source for others with the same problem / request and how these are solved with various workarounds. I can't count how often a comment on a JAC ticket helped me. Previously comments on CAC where also great, but since the ViewPort was added these are hidden as a source.

[Jens Schumacher - Released_so]

@Alex Koxaras -Relational- that's a good use-case. Appreciate it! 

We actually started building our feedback features by taking a step back and identifying the problems with JAC and other solutions. It's really the small things, such as limiting the number of votes per person or adding the option to hide them in order to reduce "bandwagon voting."

But the real difference is actually inside Jira not in the portal. Instead of having to dig through every ticket, all the feedback lands in a JSM like inbox where PMs or other team members can go through it much faster. 

[Jens Schumacher - Released_so]

@Tim Eddelbüttel the workarounds are useful for sure.

[Metin _savignano software solutions_]

@Jens Schumacher - Released_so 

I'm curious, how does it help you or your clients if a suggestion is publicly listed, but is never even looked at by anyone at Atlassian because it's one of 10,000 ideas? 

• informs everyone that the feature request has already been filed (otherwise, the same feature will be requested again and again)
• informs everyone about the status (informative, even if it is not considered or neglected)
• gives app developers an idea of what feature might be in need, is neglected by Atlassian, and could be provided in an app (which creates a win-win-win)

[Jens Schumacher - Released_so]

@Metin _savignano software solutions_ 

informs everyone about the status (informative, even if it is not considered or neglected)

I wonder if it creates more uncertainty than it informs though. It gives the illusion of being a "known issue", when most likely it isn't a priority at all. 

[Logi Helgu]

I like the JAC...had a ticket the other day that almost got to 20 years when it was resolved and I'd been monitoring it for years but thankfully we couldn't celebrate it's 20th birthday of being open ;) but nice to be able to add/comment and at least get info from others there :)

[Dr Valeri Colon _Connect Centric_]

I have zero opinion on this either way but love that this conversation is happening. It brings up interesting questions... thanks @Jens Schumacher - Released_so 

[Valerie Knapp]

Hi @Jens Schumacher - Released_so , thanks for your post.

I agree with you that something needs to change, especially in light of status-gate.

However, I don't know that taking JAC down is the right idea / the right look now for Atlassian.

Like you say, the company is supposedly committed to being open and JAC is evidence of that, a very public and (I think we all mostly agree) kind of embarassing backlog of work / bugs / stuff to do that spans many years.

However, I think having Atlassian create and publish another type of traceability tool, like a wishlist, is less transparent. How would they make and prioritise a list like this? Would the criteria be made public? Would 'we' be consulted about how these decisions are taken?

I guess it depends what the priority is. Is it to be transparent? Is to be accountable? Is it to be realistic?

I agree with you that it is difficult to meet all of these needs.

I do not, unfortunately, have a better idea, other than just to communicate more.

I think that having a parking lot of stuff you would like to get to ever, for a software company, is realistic and is going to be hard to get away from.

I agree, also, with @Alex Koxaras -Relational- , that having JAC, we can evidence to customers, okay, Atlassian even accept that this doesn't work as well as they would like it to. So, here is our proposal for how to do that instead. More than perceive this as a weakness, in my experience, customers just want to know what the limitations of these tools are so that they can take informed decisions. No one wants to buy something to find out that it doesn't actually do what you need it to.

I welcome this discussion and I look forward to hearing what other people think and for new ideas for how to improve.

Cheers

[Matt Doar _Adaptavist_]

I think Jens is talking about a revamp of jac, not taking it down. And I think I agree with him. It's not very useful for customers or Atlassian at the moment. There are too many issues that originated in Server and got cloned to Cloud. Too many duplicates. Too many one-off requests.

My main concerns about changing jac are

1.  There is a lot of information about Data Center (in particular) that has never made it to Knowledge Base articles. That information is necessary for running DC

2.  Changes that reduce the ability of customers to give feedback to Atlassian risks going in the wrong direction. Making that feedback more effective for everyone is necessary but needs great care

3. Atlassian customers definitely bond over specific bug reports, which builds community. Cutting that off would be a backward step for everyone who helps each other

[Matt Doar _Adaptavist_]

Oh I see where the killing jac idea has come from - the title!

@Jens Schumacher - Released_so would it be better as "Changing JAC" or some such, rather than the provocative "Shutting Down" ?

[Chris Cooke]

Great to hear your thoughts, as per usual Jens. But @Matt Doar _Adaptavist_ , you've got to have a clickbait title!

I'm sure everyone's tired of this lazy answer (which is why I've never given it) but if there's one thing AI is good at, it's summarising and finding patterns...

How bout Atlassian pay a Data Bounty for anyone that finds a succint way to collate or summarise large outdated data sets such as JAC in a useful and meaningful way?

[John Funk]

I would echo many of the comments about keeping the JAC open. Helpful for seeing what has been submitted and is being worked. And, as always, helpful workarounds give the user a way to implement a solution that they may have never thought about. 

Plus, how would you really get the bugs recorded along with requests? Yes, there can be a "wish list" but that's just not the same. And hiding those requests seems a bit sus. 

Suggestions - why not incorporate AI to help with updates in some way? And isn't this actually one of the functions of a Product Manager? With thousands of employees would even 31 FTEs to keep the users informed be too much to ask? 

Yes, JAC can use an overhaul - but I wonder if it is not more of Atlassian needing an overhaul and how the tool is used versus the tool being overhauled or thrown out with the bath water. @Chris Cooke needs his bubble bath to maintain the beauty - that just doesn't happen you know. 

LONG LIVE THE JAC!!