Hey, Linear is opinionated in it's philosophy of Project management and the usage of terminology. We do accommodate all the features that linear has in a general way. Plane is extensible where users can build the framework of their choice.
Height is a very general tool with it's focus on various kinds of teams. With Plane you do that as well. But it's focus is more on the Method. Method or the framework of choice that the team wants to use to manage their projects.
For anyone else frustrated, a quick workaround is to do Ctrl+FK instead of Ctrl+K on offending websites. Focuses the browser UI's search input which then makes the Ctrl+K bubble up from the browser UI instead of the website's document tree.
It's very common across lots of platforms. Slack overrides it, and it irritates me (although I have adjusted to Slack's alternative which is that Cmd/Ctrl+V turns selected text into a link with the clipboard URL, which is actually really slick).
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.
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.
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.
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.
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.
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.
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.
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.
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.”
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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 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.
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.
I've been looking for a competitive open source alternative to Jira for a non-profit I volunteer at because they cannot afford to pay for any cloud service and Trello has its limitations. Does Plane offer all pro features for open source instances as well? Does it support login via Google or other identity providers?
Edit: I should clarify, supporting open source is the best possible model for price pressure and innovation, especially in the cloud hosting space, but I also wanted to let other non-profits know about the discount if Jira is too expensive per-user due to volunteers, etc.
FYI, Atlassian has a non-profits license. While the cloud version only has a discount so you still have to pay per user, the on-prem version is free. Best part about running on-prem under this license is that a lot of on-prem extensions have opted in to atlassian marketplace licensing and offer free plans for non-profits. While this would be expensive to do in the cloud, because the plugins run on your server, it’s basically free for everyone involved. The downside is you still have to manage and renew licenses, and don’t expect too much support given the free price.
> Atlassian also offers free Data Center (self-managed) licenses for registered charitable non-profit organizations that are non-government, non-academic, non-commercial in nature, non-political, and have no religious affiliation.
Youtrack is great but complicated with it's UX. Code level extensibility with Project management tools is near zero. We are working on our extensibility framework called Propel, it gives you the ability to write code with React to extend Plane. Open-sourcing in Q3 2023.
That's a bit unfair towards youtrack, you can extend its behaviour with arbitrary javascript. It's not the cleanest development experience I had but it is powerful.
Unless I'm misunderstanding what you mean by "code level extensibility".
By the creators of Penpot, free plan is basically only missing premium support. Not sure about the login though...there seem to be some plugins for it, not sure how that works with the hosted version?
We have a singular focus working only on Plane and making it big for everyone. We are still in early stages, so had to rush on few decisions, but we treat every user the same.
Recommend Clickup highly for multi user flows on a free tier (infinite users), only issue you can not attach many files (have uses google drive link for that earlier)
OpenProject (www.openproject.org) is a fork of Redmine. I have not used it, but I did extensive research on it a couple of years ago while looking for a new project management system for our division. I think it is worth a look.
A good alternative to jira and other tools used in application lifecycle management is tuleap [1]. The PM/agile part is very configurable and it is also offering integrated wiki, gitolite, and hooks to integrate with some CI/CD. Also LDAP and OpenID integration is available in the community edition [2].
Can it auto-delete issues untouched for the last 30 days? Idk if jira can, but this would be the single biggest productivity boost to any organization forced to use this sort of software.
Like it or hate it, there just isn’t enough time and energy to do all the things you might like to do. Triaging and prioritizing are usually best done manually, but “it hasn’t been worked on” is a cheap and acceptably accurate proxy for “not that important” for some teams.
Taking a bug report and making a good workitem might be a lot of work. If the same thing happens 2 years later you'd need to do the same work again if you already deleted the bug workitem. If the old stale bug ticket was still around you'd both have a) saved the work of writing it again because you would find it when searching and b) have a very good indication that the bug you are triaging might not be that serious because it has been seen before and not prioritized.
You could just automatically mark it "stale" or whatever instead of hiding it, which would give the best of both worlds. Automatic sunset for the item, without the duplicated effort.
Sounds like you've never worked on a project with hundreds or even thousands of backlogged issues that will never be worked on - it is the same as being deleted except is causes visual clutter.
I agree to the idea of not ignoring Indian names. We do have India names as well on certain screenshots. To distribute well we used all kinds of names. We tried our best to globalize.
Native Spanish speaker that builds software for English speaking markets: I don't think I would write a software or make screenshots where I would think first to put names like Juan or Pedro in them if the target audience is English speakers.
When you're writing English it just feels like the names flow better, that's all (like, avoiding stutter in a sentence, but with names). I don't think it would be fair to say we're just not honoring our roots
I played around with Plane locally a little bit about a month ago - I think it's really promising! I wish the documentation was a little better, though; I had to dig around through the source code to figure out how to get the OpenAI/GPT-powered features to work locally. I also wish it supported the gpt-3.5-turbo model instead of relying on the InstructGPT models (like text-davinci-003) for those features (while this isn't exactly a "chat" use-case, I think the chat model would still do a good job, and the 1/10 token cost would be nice).
I'm planning to set up a Plane instance for my friend group as soon as it supports OpenID Connect (SAML would work as well, but I imagine OIDC is coming first, since it's a lot more sane). We have some small projects we maintain, and we desperately need a nice issue tracking tool like this.
Walk through video please. For people on mobile checking it out it’s more convenient to watch a short video. Serious about short, I’m not going to start a half hour long video while browsing. Also subtitles.
Just about any ticketing system (including the established open-source ones) could be described as an "alternative to JIRA", even if bare-bones, so you might be better off describing the unique capabilities or UX that makes this one special. (And if mentioning JIRA at all, say what you offer to people converting -- $dayjob would probably be interested in one that seamlessly imports tickets with extra custom attributes and custom workflow which refers to them, but implementing that is not an easy lift.)
You reminded me of Jira's most hilarious feature; if you type JIRA in a ticket, it auto-corrects it to "Jira". This one better do that or, uh, it's one less checkmark on the comparison chart!
Worth noting - I am not sure how the legalities of it all map out but although it is Apache licensed, it appears to depend on MinIO which is AGPL for self-hosting. That may be just a swappable back end S3 layer but if you want to self host this you may need to be comfortable with AGPL (for those in environments that are allergic to AGPL ...)
Please, kill Jira and Confluence. I hate Atlassian tools so much. The user interfaces are sluggish no matter the hardware you're using... it's a shame it became almost a standard in our industry.
I just opened a view mode page in confluence, and it made >400 calls until fully loaded. ~80 XHR calls and >300 js files being loaded, in what world that is acceptable?
Seems to me that "open source alternative" is missing the key thing which the company provides. Which is support, and a button for "call us" as an enterprise plan.
Sorry, I don't understand what you are trying to say here.
If JIRA is the "most hated" brand and at the same time a very popular issue tracker, then "Alternative to JIRA" sounds like, "here's an alternative to the product you so hate" isn't it ? I mean why would I look for an alternative if I didn't hate the thing I am working with or thought it was not good enough?
Right, so perhaps the answer to that is not to make your software "Enterprise". There are a lot of idiots in management; do not give them what they ask for if you want your product to retain any vestiges of quality.
From a brief look at the code, it appears to be written in python. I am surprised at that choice for an application that has speed as a goal. Of course database performance is likely to dominate, but every bit adds up. I feel like I’ve only heard bad things about trying to maintain a service written in python long term (both from a performance perspective, as well as ease of code maintenance). This is not first hand knowledge though. Does anyone here have experience to comment on the wisdom of using python in an application like this?
From what I can tell, it's Python for the API server, Typescript for everything else.
FWIW, Python servers like this are just a wrapper around `gunicorn` or some other performant low level tool. For some teams, it's easier to define a schema in Python for a couple years now due to some very innovative libraries with easy-to-use decorators.
I have no personal experience with using it in production or for an extended amount of time however.
235 comments
[ 4.2 ms ] story [ 307 ms ] threadThese types of shortcut key overrides are why I've got them disabled in my browser by default.
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.
Edit: for Plane, the GPT powered pages are a non-starter for HIPAA unless the feature can be completely disabled.
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...
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.
Within 3 seconds of reading the GitHub page I was sold. It’s already on my todo list for next week.
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.
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.
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.
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.
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.
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.”
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?
Luckily it's a nice space to contract in, making simpler dedicated interfaces to the heavy enterprise stuff.
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.
As for being proud, with roughly 8k (?) employees I imagine you get the full spectrum.
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.
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.
Perhaps that’s because they’re spending too much money on supporting companies who are struggling with upgrades.
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.
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?
As the saying goes, Jira is fine, the only problem is that it is Turing-complete.
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.
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.
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.
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.
The other problem is that you still need to track when all the tests for the feature have been written.
The project management system is the view.
The model shouldn't have to change to accomodate the view.
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.
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,...)
but it's easier (and probably healthier) for jira to soak up that hatred. jira's good at that.
It's unfathomably tragicomic how the alternative offerings are also UX nightmares. PM tools are cursed, it seems.
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.
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.
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!)
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.
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…
Truly just a horrifying situation to be subjected to.
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.
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.
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.
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.
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.
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.
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.
BUT it is absolutely possible to configure Jira to be horrible to use. Add lot’s of extra fields, force complex workflows etc.
It's... free? Isn't that a pretty big difference? https://www.atlassian.com/software/jira/pricing
Plus, even if the software itself is free, you still have to host it somewhere.
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.).
That’s the value prop
- It's not Jira
As a development tool for stories / tasks and bug tracking I don't enjoy it.
The fact that it’s basically the same thing is probably a positive for a lot of people shopping for alternatives.
Edit: looks like you do [1]! Perfect! I'll sign up shortly and give it a spin.
[1] https://plane.so
FYI, Atlassian has a non-profits license. While the cloud version only has a discount so you still have to pay per user, the on-prem version is free. Best part about running on-prem under this license is that a lot of on-prem extensions have opted in to atlassian marketplace licensing and offer free plans for non-profits. While this would be expensive to do in the cloud, because the plugins run on your server, it’s basically free for everyone involved. The downside is you still have to manage and renew licenses, and don’t expect too much support given the free price.
> Atlassian also offers free Data Center (self-managed) licenses for registered charitable non-profit organizations that are non-government, non-academic, non-commercial in nature, non-political, and have no religious affiliation.
More at https://www.atlassian.com/licensing/purchase-licensing#trial... under the faq question about non-profit pricing…
Unless I'm misunderstanding what you mean by "code level extensibility".
By the creators of Penpot, free plan is basically only missing premium support. Not sure about the login though...there seem to be some plugins for it, not sure how that works with the hosted version?
The per-project wiki feature is useful for documentation.
Zammad + Taiga.io|Redmine + Growi|Xwiki + Rocket.chat
Edit: in the spirit of the thread, also try Plane.
[1] https://www.tuleap.org/
[2] https://docs.tuleap.org/administration-guide/users-managemen...
You could just automatically mark it "stale" or whatever instead of hiding it, which would give the best of both worlds. Automatic sunset for the item, without the duplicated effort.
When you're writing English it just feels like the names flow better, that's all (like, avoiding stutter in a sentence, but with names). I don't think it would be fair to say we're just not honoring our roots
Also you could use "Joe" and "Pedro" instead. To me it seems even more global.
I'm planning to set up a Plane instance for my friend group as soon as it supports OpenID Connect (SAML would work as well, but I imagine OIDC is coming first, since it's a lot more sane). We have some small projects we maintain, and we desperately need a nice issue tracking tool like this.
PRs would probably be welcomed.
I think labelling would get us out of the woods. Schema would be preferable, but there’s no reason why labeling won’t work.
I plan to give it a go at our consultancy next week, thanks
Mmh.
I like that it's opensource, that way product owners can become even more inventive with great ways of making a process cumbersome
Indeed it is a shame that they still a thing.
If JIRA is the "most hated" brand and at the same time a very popular issue tracker, then "Alternative to JIRA" sounds like, "here's an alternative to the product you so hate" isn't it ? I mean why would I look for an alternative if I didn't hate the thing I am working with or thought it was not good enough?
FWIW, Python servers like this are just a wrapper around `gunicorn` or some other performant low level tool. For some teams, it's easier to define a schema in Python for a couple years now due to some very innovative libraries with easy-to-use decorators.
I have no personal experience with using it in production or for an extended amount of time however.