Hacker News Reader

Comment by smallerfish | Hacker News Reader

I love seeing competition for Jira, because it needs to die, but I think you need to do a better job explaining your value prop. Your first bullet list of features doesn't really make it sound all that different. Why would I have a better time using this than Jira, bearing in mind that I'd be giving up custom workflows and probably a lot of integrations? (No shade intended. If you can answer that concisely, put that at the top of your copy.)

Also, please consider finding a native english copywriter to take a run at your writing. It's readable, but not fluent, and overly filled with jargon.

View on HN

Is Jira that bad? It sure is a mess, but that's because its requirement are a mess. It is not SAP but that's the idea, something that sits between developers, testers, management, customers, etc... People who want different things, speak different languages, and somehow need to work together.

If you just want an issue tracker, there are many options. Bugzilla, Mantis, GitHub, GitLab, Gitea,... Some of them customizable via plugins. Heck, you can even do it with Excel, I don't recommend it, but it gets the work done at many places. I mean, it is just a shared TODO list.

But then you want people to get notified by email, and the boss want a colorful dashboard with progress graphs, and QA wants a documented process, and developers want to attach tickets to their commits, project managers want time estimates, customers want to report bugs, sales want to send invoices, etc... That's how you get monsters like Jira, because the organization itself is a monster.

Having used Jira for only a modest 12 years, I have had multiple stages of feelings about it. I agree with the parent that “everybody” hates Jira because “it’s too complicated” — yet when developers try to use a lean, simple tool like Pivotal or Trello, inevitably other stakeholders demand something better for business users, these simpler tools can’t deliver that, and the replacement ends up being Jira 99% of the time. I’ve started tech orgs on multiple issue trackers and this plays out every time.

Also, I hated Jira before learning a lot of its features and how to use them, getting frustrated that everything is not just a setting, but something meta where you need to adjust a “scheme” and understand how it works with the other data objects in the system. Eventually I learned it, just in time for Atlassian to put a lot of effort into a candy-coated, “simplified” set of defaults that hides 99% of the system’s power and abilities.

The main thing I actually don’t like about Jira is that: its insistence on setting up all new projects with infantile, Trello-like schemes, which then encourage sloppy setup when you start customizing unless you’re very seasoned with Jira. I think they should consider training an AI to “do what I mean” and help users to build out their setups —because transitioning from the “out of box experience” which I call “Expensive Trello” into a sophisticated workflow which actually models the business processes correctly and protects you against breaking your agreements, while making it easy to understand what to do next, is very difficult. In all but the biggest orgs, i don’t think it ever really happens.

I don't know what value non-developers are getting out of Jira, because I've been asked to produce reports out of Jira at different times and the only thing they ever want is "give me a list of all the X" or "graph the number Y across all the projects".

The one thing they all do is go in and mess with the issue workflows: they never improve the workflows, but they sure love adding states and restricted transitions and renaming them...and then promptly ignore all of it because it turns out your 3 layers of "review" transitions don't actually have any staff assigned to look at them, it's just all the same guy who either spends all his time updating the issue as he works on it or just hits the transition button 3 times when he's actually done with it.

Nailed it, the biggest issue imho is those state transitions. Why make a state that can’t transition to all others? It takes forever to tease out the intention behind it. State machines are notoriously difficult in code, why add them into something unnecessarily?

We got that from the last audit. They don't like it if everyone could set the state of some ticket and thus circumvent the required workflow. A lot of companies develop certified software and thus have the same requirement.

Ah that makes sense, we’ve got a process certification as well.

Hugely agree that if in practice it’s just an extra click by the same person that’s a bad pattern. And you see it a LOT. Hard to justify even using a bespoke workflow when it just adds “digital paperwork.”

OTOH Jira does support a way to force you to build a process you’ll honestly follow — there’s a validator that says the person who transitions from Y to Z must be a different person than from X to Y (or say, that it must be a member of a certain team). :)

As an EM I think it is my job to ensure as little paperwork as possible, so I monitor this to make sure workflows don’t waste people’s time, using automations, context-sensitive paths through the workflow, etc. for instance I have a transition that skips past ALL of the steps and doesn’t even need to prompt the user, for when an issue needs to be resolved as “working as intended.”

>because “it’s too complicated”

I personally "hate" Jira because it's so dumb.

I open an epic, to see the stories that still need my attention, it shows all the stories, so I hit the "Hide done". Then I thoughtlessly click on one of the stories, I edit it, go back to the epic, and now it shows all the stories again. Rinse and repeat.

I open a screen, it loads slowly, when I think it's ready I click on whatever I wanted to click. Apparently, it wasn't quite ready, so by the time my mouse-click lands, I click the wrong thing, which brings me to a new screen, so I have to go back to where I came from. Rinse and repeat.

I open an epic, click the button to "Add a child issue", it prompts a "task", I want a "story", so I have to change the selection in the dropdown. Next time, it prompts again a "task". How many times did I mistakenly make a "task" where I had meant to make a "story"?!

There's this sort of silly (to me) things all over the place, which has often made me wonder: do these people use this software themselves, and if so, do they take any pride in it?

This applies to many systems I've seen and my short summary of that is "the bigger the system the more it resembles CRUD scaffold, because they stop implementing specific user flows".

Luckily it's a nice space to contract in, making simpler dedicated interfaces to the heavy enterprise stuff.

> which has often made me wonder: do these people use this software themselves, and if so, do they take any pride in it?

Agreed - Jira is functional but there are endless little annoyances like this. My usual problem is that I work across two project boards, and no matter what board you're on, the default project that Create Task picks is the last board that you created a ticket on, not the project for the current board that you're viewing.

Random idea, untested. Maybe it remembers client side? Then using two different browsers (or users in the same browser) could separate them.

They do use it: https://jira.atlassian.com/issues

As for being proud, with roughly 8k (?) employees I imagine you get the full spectrum.

I agree with this sentiment completely. It's a "do everything for everyone" but "impossible to do anything" software.

Excel sheets ALWAYS is simpler to understand what's going on at a high level, but then devs want, then biz wants, etc etc and i just end up at the soup that which is jira.

It's annoying because there's a always a better individual tool (pivotal, trello for devs, excel, powerpoint for biz), but none of them inter-op and then you're stuck at jira which does it all but not very well. It really feels like salesforce, just an absolute mess but it can really do everything.

Bad management demands bad tools.

> Is Jira that bad?

As someone who had to admin an on-prem installation of various Atlassian products, upgrades were always a nightmare: you could try multiple dry-runs to make sure data tables were updated, and plug-in upgrades were good, but invariably there would still be a good chance that something would still go wrong when you tried it with production.

The workflow we settled on was basically leave the old version alone, rsync over all the data to a completely new app and DB servers, and do the upgrades on the new systems. Any attempt at in-place upgrades was just asking for trouble.

Anyone who was prime on the software was very happy when The New Guy on the team arrived due to personnel churn and they got handed the baton for dealing with it.

Atlassian seems to be pushing hard to get everyone into their cloud. I’ve heard, but don’t recall details and have no direct knowledge, that the pricing for an on-premises install has gotten outrageous.

Perhaps that’s because they’re spending too much money on supporting companies who are struggling with upgrades.

They eliminated the server-tier licensing so now you have to go cloud or go datacenter, which is much more expensive.

I feel bad for the people that have to the Jira updates where I work - every time it happens it seems to take forever because it needs to "reindex", and they try and start it in the early evening but it still seems to bleed into business hours the next day.

Linear and Height are not monsters but they do all those things, if I not mistaken.

Having used linear (we switched to Jira) I have to say its near-complete lack of automations, and no REST api, only GraphQL (and not a complete or reliable one at that)… did not impress me.

There is a big feature gap. And also Linear is even more opinionated, and seems to exist mainly to get you to follow their pet process.

> Is Jira that bad?

Jira itself is fine. It is very powerful, and with that power, it can be setup "wrong". That all stems from opinionation. On itself it's an empty box, right?

My biggest issue with Jira (and Confluence) is that it is unbearably slow. At every company I've worked at, we've used Jira, and everytime, it is slow.

It all comes down to managers and PMs. or wanting to do their job of communicating status to stakeholders so they try to automate it with the monstrosities.

> Is Jira that bad?

As the saying goes, Jira is fine, the only problem is that it is Turing-complete.

The problem I see is that Jira encourages "management by looking at Jira" - effectively Jira becomes a second source of truth that is unconnected and unconstrained by the actual truth (the code). Jira acquires state that has to be carefully maintained as a separate operation by the developers to keep Jira's state in sync with the actual state of the project. Since most of the organisation are looking at Jira, the effective source of truth becomes Jira's current state, and the developers end up running to try and keep the actual project in sync with Jira. Or they become disconnected and Jira's state becomes completely independent of the actual project state (tickets being marked as "done" that aren't complete, or sometimes even started, because it doesn't matter because everyone is looking at Jira and not at the code).

I would love to see Jira state somehow derived from the state of the codebase. Tickets get marked complete when they are actually complete in the code, with tests and documentation and everything, because the ticket state is derived from the code state.

You can write glue for whatever hosts your repository to make api calls to Jira.

Say you have some code that needs some changes but at a later time, you can put a comment above it (or really anywhere)

// JIRA: MYPROJ-123

When the glue sees that comment disappear from the codebase, it can mark the ticket as done.

Useful, I guess, but that seems to be inverting the responsibility. The code needs to have comments inserted into it referring to the state of Jira, rather than the other way around.

The thing I'd like to see is that ticket "Write the login page" is automatically marked complete when the codebase contains a working login page, there are unit and integration tests for the login page, and maybe (depending on how you do your documentation) a set of comments on the API methods involved describing their use in the login process. All without those code elements ever needing to know the ticket exists.

What you're describing looks like magic to me. How would your ticket system know, without it being told (in some way, e.g. through backreferences from the tests), that a particular feature has been implemented? That's very likely going to be a formally undecidable problem.

Writing end-to-end UI tests to validate a certain behavior and then automatically resolving a ticket once those tests pass seems really cool though. Not sure how realistic in practice, but it's definitely an interesting concept.

yeah, something like TDD but the ticket is actually a set of integration or end-to-end tests that must pass for the ticket to be "done". Hmmm, interesting...

edit: actually, thinking about it, you could do plain TDD and track the tests as the tickets. Write all your tests for the project first, then track how many are passing as the progress measure.

Sure, but then you have to tag those tests with the ticket, and GP didn't want to have references to JIRA inserted in the code.

The other problem is that you still need to track when all the tests for the feature have been written.

The code is the model.

The project management system is the view.

The model shouldn't have to change to accomodate the view.

Code is not a source of truth, it is an attempt at partial realization of an incomplete understanding of a bunch of contradictory assumptions about what’s true at a particular point in time.

It's a source of truth about what code has been written.

The code itself doesn't even contain much of the information relevant to coders, you'd have to also look at the git repo, its history, its commits, etc.

The code, or the repo, however are in most cases not the source of truth for a business roadmap, prioritisation discussions, estimation, customer feedback, bug reports, and so on.

It's a myopic view to only look at the code without any of its context and conclude that it's "the" source of truth.

Also, I don't know about you, but most places I've worked haven't struggled with keeping the code and JIRA in sync.

I've noticed it particularly with outsource teams where the communication is difficult. The team update tickets with what management expect, not what code has actually been written.

I have used Jira at several place, and every time that it worked fine Jira was the source of thruth for the project. There was no shadow tracking beside it. So everybody updated it happily and used it.

You can't do that based of the code because the code is limited to its content. How do you track everything that isn't in it ? (requirements, relation with other teams, delivery to customer, customer tickets,...)

Jira sucks in the same way that email sucks - the platform is fine, the stuff people put in it sucks. you probably don't hate jira, you hate your boss, or their boss, or your colleagues, or your business's development practices or prioritization. or your developer's productivity levels, if you're looking at it from the management side.

but it's easier (and probably healthier) for jira to soak up that hatred. jira's good at that.

even a default jira is unusable just from a slowness perspective.

slowness, I can accept, but the extremely bad UX, byzantine inconsistency, some parts are SPA some are long forgotten wizards with useless and completely idiotic next-next-finish steps, some functions are so close to useful, but ultimately fall short because even though Jira can do anything it can't simply graph a fucking JQL result set over time, it simply doesn't have anything useful to report by default. Epics and subtasks and story points seems useful, sure, we picked it because it has the best scrum support, but there's no aggregation of points from subtasks to tasks. Oh, yes you can DIY with ducktape-and-hate using the new automation functionality, but it'll have the same bad UX of course, because it's not integrated, because it's Jira. It's hell. It's bad. It's ridiculous.

It's unfathomably tragicomic how the alternative offerings are also UX nightmares. PM tools are cursed, it seems.

i'm not really sure what your metric is here, or if you're talking about their on-prem version. but the jira hosted by atlassian seems like it runs at about the same speed as most websites. i'm not going to say it's blazing fast, but it's acceptable.

I mean I can't even use the one they host because I wait for things to load and spin.

It's really not bad. It's gotten much simpler and faster in the past 5-ish years. If you take the time to learn it, it does pretty much everything you want, and there's always the API, extensions, automations, etc.

But it's an opinionated tool. Almost every person I have ever worked with has never read the docs, so they just sort of suffer and complain and never learn that they're using it wrong. I'm the guy on every job that has to teach the team how to use Confluence and Jira correctly. My biggest challenge in making Jira work well is convincing coworkers to stop using it wrong. (They'd rather come on HN and complain about it than read the docs or take a Udemy course)

All this is compounded by people who don't even know how to do Scrum or Kanban or even basic project management, so their complaints are also often just people who don't know how to work. Which, again, is most people I have worked with.

I think one of the biggest problems with Jira is that it's taken the approach of so many other "Enterprise" products made by talentless teams: they just add all functionality into the app that anyone ever asks for.

The result is that for some of the companies I've worked for, each team's tickets have different but very similar "workflows" using custom state labels. In some projects when I go to close a ticket, it offers me approximately 30 different semantics which which to close the ticket. These include things like both "Done", and "Completed". What the fuck is the difference between "Done" and "Completed"? I do not know or care whether it is Jira that has populated this dropdown with such embarrassingly unintelligent crap or my company: if the latter then Jira should have neither encouraged nor even made it possible.

I've worked at a company that had Cancelled instead of Abandoned - so if you try and "cancel" a ticket you're given a model with two action buttons - Cancelled and Cancel: Cancelled cancels the ticket and Cancel cancels the modal.

You’ve hit my Jira pet peeve, kinda - accepting the default of naming the transition the exact same as the state it goes to.

Transitions should be verbs. States should be adjectives.

So your transition should have been called “Cancel” so your modal would have had 2 cancel buttons :D

(Or yes, another term should have been picked!)

Yes Cancel and Cancel would have made no sense, and I think that should have told someone that Cancelled is an awful state name.

I used JIRA at, I think, every single company I've worked at and I never really liked it much...

But the company where I work at right now has a really well set-up JIRA board where most things that I need to do are easy to so and there are clearly defined workflows. Compared to the morasses of legacy code I have to wrestle with, I find JIRA now to be one of the least troubling aspects of my work day.

I'm sure it was super painful for the people who had to actually set up the current flows, but I guess that once you customise JIRA to your needs, it can work really well. The issue probably is that many companies don't want to bother setting up good, streamlined processes, or just don't know how.

Now, Confluence on the other hand... I have no excuses for it. I can't understand how a documentation tool can have a search feature that is unable to find what you're looking for basically every single time.

> I'm sure it was super painful for the people who had to actually set up the current flows, but I guess that once you customise JIRA to your needs, it can work really well. The issue probably is that many companies don't want to bother setting up good, streamlined processes, or just don't know how.

It’s actually not as bad as you’d think to set up. The reason Jira is so universally hated is because everyone uses it and very few people spend any time thinking about how it should work. In most companies it gets adopted by shadow IT, and is supported by whatever team member was most excited about it. But their competency isn’t Jira configuration, it’s widget support, so they spend the bare minimum amount of time setting it up using online tutorials and various blog/SO posts. They don’t follow any recommended best practices because they don’t know they exist. Eventually that person leaves/gets promoted or the system just becomes so widely adopted IT is forced to take over support. By this point though, the damage is done, the system is a mess of half baked badly implemented ideas. And there’s no budget/time to start from scratch. So it just limps along, being hated but no alternative being offered… until some VP discovers ServiceNow…

And then you have some poor suckers doing their damnedest to balance all the demands of all the middle managers who all want servicenow customizations on priority.

Truly just a horrifying situation to be subjected to.

Do u happen to work where I work? Lol

I hope not. I'm trying to get out of that shit, and you don't want half of my workload if you're one of the leftovers

I fight a lot about unnecessary customization, but the one place that I’ll never back down on is touching the priority/urgency matrix.

I don't know, I've seen that extreme, but I've also seen the other extreme.

People with vast knowledge of JIRA, obviously far more than anyone else in the org, developing vast dashboards and labeling systems. Every ticket has to be properly groomed and properly built (even if not useful).

That isn't always better.

Knowledge doesn’t equal expertise.

JIRA has a very simple initial onboarding story, especially in comparison to servicenow or SAP. But it’s got a lot of hidden complexity that can make it super powerful. That power can become its downfall if implemented badly. Vast dashboards and labeling systems is improper implementation.

True, and worse, this kind of approach sounds like expertise. I've found some people are amazingly good at selling continuously expanding complexity of management overhead.

jira-1369 is a 20 year old bug of email notifications not being put into a digest and instead flooding users.

I for one feel like I grew up those people and we should share our wedding and other milestone photos and announcements on that chain.

Even though I’ve come to like Jira there are a few of these 15-20 year bugs that are just frustrating beyond belief. And a Jira PM will duck in there every 8 years or so to say they’re not considering it and then run away. Mine is how it’ll let you create infinite case variations of Labels, even though Labels are case-insensitive when querying, but it means the accidental variations people will make crap up the autocomplete forever.

Or the fact that Components or Versions can’t exist across multiple Projects. Thankfully we did basically automate Version management using their Automations to basically fake it. Thankfully Versions in JQL are searched by string instead of being instantly converted to ID like Sprints are.

Part of me feels like writing a new interface of what I need to Jira using their API to get things how they're needed while maintaining some meaningful compatibility.

Then I remind myself I'm not the only person to ever think that.

What amazes me is the number of times JIRA has landed at a clients while we are working with them (from us introducing them). It is excitedly rolled out to hundreds of employees on a project eam after they see what it can do with modifications for their workflow.

Every single deployment has eventually been shut down because Confluence can't digest updates every 5-10 minutes, nor can Jira.

A plugin isn't realistic in some cases, so some other ways was found around it.

To me personally, Jira was the best tool I've used so far (used a few of them, but not very many).

But I still was not too happy with it back when I used it - main reasons being extremely slow load times (we had the cloud version, not self-hosted) - and lots of annoying inconsistencies, like "create issue" using a completely different editor than "edit issue", etc.

It's pretty bad. The actual interface has improved a lot over the last 5 years, but it's still very unintuitive and has weird limitations. For instance you can't have proper hierarchical tasks. In Phabricator you can just give tasks a parent task and it will display the whole hierarchy. Very useful. In Jira, a task can be a child of an Epic... and that's it. You can have "subtasks" but they aren't really full tasks so you get 2 or 3 levels of hierarchy max.

Another example: tasks can't be part of more than one project. Have a task that affects multiple projects? Tough. Pick one.

The backlog doesn't update immediately when you edit tasks on it. You have to refresh.

But a big part of the problem with Jira is that it is highly configurable and you always end up with project managers massively overcomplicating things. You get dozens of issue types, dozens of statuses, weird automation rules etc.

It's not awful, it's just surprisingly bad at its core task.

It’s “death by a thousand cuts” for me. On planning meetings I usually take notes on a notepad and transfer that to Jira after the meeting, because interacting with Jira directly (plus the swearing) would make the meeting take double the time.

I think Jira is fine and it’s ok tool. Nowadays the performance of the cloud version also has been good.

BUT it is absolutely possible to configure Jira to be horrible to use. Add lot’s of extra fields, force complex workflows etc.

Jira was acceptable when it was easy to run and cheap ($10/year for 10 developers).

My problem is that it’s expensive. $100/year/user for cloud and minimum $40k for “data center” hosting.

Also, it’s java based so updated are kind of a pain with ears and jars and wars and manually application. And there have been a few zero days and data loss.

At this price, I want something else. I don’t think issue tracking is a “big deal” but Jira is making it a big deal because of its price and security.

I’m trying to get by with gitlab and GitHub issues.

The value prop is that you can self-host it at all, which JIRA now discontinued unless you pay ~$50k per year.

Within 3 seconds of reading the GitHub page I was sold. It’s already on my todo list for next week.

This! Jira works ok and gets job done, like the UI and the default workflows or not. But for those who are not willing (or required not to) outsource all their business to the Cloud it just doesn't exist anymore.

> I love seeing competition for Jira, because it needs to die

I think when I die in ~50 years that HN will still be filled with stories ragging on Jira, or whatever it is that eventually replaces it. It's like the pastime that will never end.

To be clear, I think it's great to see open source projects like this, and I think increasing competition is a really wonderful thing. I also totally agree that Jira has lots of room for improvement, with performance probably being the most common gripe. But I always smirk a little to myself when I hear complaints that are solely from a particular point of view (usually an individual developer). Project management tools have an extremely difficult task of needing to fulfill a gargantuan range of requirements for many varied stakeholders (frontline devs, dev managers, product managers, business leads and execs, sometimes end users depending on ticketing functionality, etc.)

Some simple pieces of evidence:

1. For one, just look at the varied list of comments already coming in on this story "does it support multiple issue types or tiered issues?", "Does Plane offer all the pro features for free because we can't afford to pay anything for it?", "Does it support Google login or other identity providers?", "It needs a walkthrough video that must be short, I'm not going to look at a long video", "Is Ctrk+K a good shortcut?", "Can't add an issue on iPad", "Can it autodelete issues after 30 days of no changes?"... Point being, for any project management tool, you're going to basically get feature requests as varied as the number of comments, and I think I see this more frequently with project management tools than almost any other type of software.

2. Think about the legions of Jira competitors that have popped up: Asana, Basecamp, Monday.com, Linear, Rally, YouTrack, ClickUp, Trello (obv. under Atlassian now, but can't count the number of times I've heard "We loved Trello because it was simple and easy to get started, but we eventually outgrew it and needed additional features."), etc. etc. I have yet to ever hear one of those competitors being universally loved. On the contrary, I've seen cases where a competitor is touted as "the next big thing", and then when it gets more popular people talk about how much they hate it (Asana comes to mind in that regard).

In general, I don't think the problem is the tool, I think that most people just don't like to do ticket management, so it's all a case of looking for the "least bad" tool out there.

I can list all sorts of issues with JIRA, but completely agree with you. The hate for JIRA is typically hate for the companies process(es). I've used JIRA for years and it's fine. But, we did a lot of work (and still do) to make sure our development process doesn't suck. JIRA has done a good job adapting to us.

As soon as we add a new feature to Shortcut people inevitably use it in a way that's complex and unexpected and that causes a large portion of the team to hate it. It's a very hard dance to do.

Hi there,

This is Nitin from Plane. Your;s is an interesting take on project management tools. Quite understandably, no one can go out and try to solve everyone's problem. However, at Plane our methodology is "Tasks meet Methods", and we will try our best to do everything fitting in to this methodology.

We would love to see you try out Plane and share your valuable suggestions. Plane is new but its evolving quite fast.

> Your first bullet list of features doesn't really make it sound all that different.

It's... free? Isn't that a pretty big difference? https://www.atlassian.com/software/jira/pricing

Not really. Jira licensing costs are on the order of about 10 minutes of employee time per month. So, if it is even slightly worse it's a financial disaster. (Of course, Jira itself is hell, but then what is a likely-buggy and feature incomplete version of hell?)

Plus, even if the software itself is free, you still have to host it somewhere.

That oversimplifies the cost though. Take your typical 200 person company. Maybe 20 of them develop using Jira, 30 more create issues, and then 10 more poke their head in there so they can check on developers and project managers. So of those 60 registered users 40 of them spend just about 20 minutes a month in it. You still have to pay for them though. The problem grows because we need to run similar numbers for every Saas this 200 person company uses. You've got Jira for project management, Zen/FreshDesk for support issues, Mailchimp for spamming customers, CMS, CRM, payroll, etc.

You end up with many many hours of employee time per month spent on licenses for SaaS products that you never own, can't control, and often can't extract your data from if you want to bail.

So yeah, as a middle manager trying to cut costs, any free alternative to a SaaS product sounds good to me. It beats dribbling out licenses piecemeal and living without core functionalities (looking at you monday.com) to stay within the lowest payment tier where I can see that 10 minutes-employee-time per month.

I admit that paints products like Jira in a bad light and ignores all the upsides (no hosting issues, upgrades are automatic, etc.).

I haven't tried the app, but I'm almost certain you can make certain favourable comparisons of page render speed.

Our page speeds are currently standing at ~350ms at this point. we are trying hard to make it < 100ms. Feedback helps.

You’ll have hook it up to the network at some point. And then you’ll want to add IO.

If page render takes 100ms you’d better have some pretty complex animations. Data and bandwidth should be at least 80% of your web app speed, and you should work on optimizing the other 15% that is server side CPU bound.

One feature they have that Jira does not: the ability for a customer to avoid multi-week outages. Jira went down for some customers and took weeks to restore. A customer could avoid this possibility by hosting locally, but I hear Jira is phasing out local hosting while Plane lists it as a feature.

Another feature Plane probably has: not being horribly laggy. You could make a ticket in Jira with a bunch of links or whatever the hell it is that makes Jira load so slowly, and make an identical ticket in Plane, and compare the loading times. From my Jira experiences it shouldn't be hard to be 10x faster.

https://www.techtarget.com/searchitoperations/news/252515706...

Thanks for the feedback! We will definitely work on it.

One advantage you have: a BAA, required for HIPAA compliance, is only available with a very expensive Enterprise plan. For HIPAA compliant organizations, a self-hosted alternative could be very attractive.

If I'm not mistaken, they want a minimum of 800 seats to sign a BAA. It's absolutely crazy, and forced my company to choose a significantly worse product in its place.

Edit: for Plane, the GPT powered pages are a non-starter for HIPAA unless the feature can be completely disabled.

I've used it as a stand in workflow/case management tool in dev and production apps a few times. e.g. when presented with a lot of detailed requirements on case management from product managers, and knowing at an early stage they are far too detailed to stand up to the reality of being used in the business, I've argued for simply creating a new project in an existing well-speced Jira instance with minimal workflow, taking that live as a prototype and modifying the workflow later, possibly with the goal of getting better specs for replacing it with something custom-built.

As a development tool for stories / tasks and bug tracking I don't enjoy it.

Isn’t a big part of the value prop not paying a big per-user bill to Jira?

The fact that it’s basically the same thing is probably a positive for a lot of people shopping for alternatives.

I agree. Call out famous competitors like JIRA and explain how you are better. Don't make me think. It won't cost you any business if everybody already knows them.

From glancing at the bullet points and feature list, along with commit activity, the value prop seems to be the product and its features... which seem polished and useful.

> I'd be giving up custom workflows

That’s the value prop

Value prop:

- It's not Jira

Reply on news.ycombinator.com