Plane: Open-Source Alternative to Jira | Hacker News Reader

Plane: Open-Source Alternative to Jira

github.com

638 pointsviharkurama228 comments

The Problem with Jira is not that it's dumb or too sophisticated.

The first problem is that everyone, even in the same team or org, needs something different from it. Sometimes it is even single individuals needing one particular thing one time, and the same day for another workflow or view another thing. It is when Jira caters to the wrong use case for you right now where the a lot of frustration arises.

In a similar vein, it wants to cater devs, coaches, POs, business people, customers and all of them over various orgs with drastically different workflows. Serving everyone equally must lead to a mediocre experience. You will always miss something, while there is so much stuff you don't need or want and you have to work around.

Arguably, this has become better a lot in the last 10 years, but you will always long for "something better".

But the most painful issue is that in some orgs Jira is the workflow, instead of supporting it and staying in the background. At some point people are only sending around ticket links, commenting on tickets, requesting people monitoring their queues. This creates overhead, redirection and Jira becomes a distraction you need to handle.

As a result Jira becomes a proxy for all the things going wrong with your daily work and a problem of its own.

Catering to many different kinds of people explains some of the bad stuff, but it does not explain, why seemingly every single Atlassian product including Jira sucks at parsing Markdown or supporting Markdown well. In the big picture maybe some things suffer from catering to too many audiences, but in the small, it is just lack of good engineering. Basically any markdown parser you can install at no cost and even with pushover license for any popular programming language works better than what they cobbled together. Is it a case of some "senior" person sitting somewhere sheltering their brain child?

Also they seem to be immune to feedback, which they wanted to collect in Confluence, using some popups.

>it does not explain, why seemingly every single Atlassian product including Jira sucks at parsing Markdown or supporting Markdown well.

Australian here, I can provide some clarity on that. Australians in general are fairly lazy; we like to do the bare minimum necessary to get the job done so we can knock off work and grab a beer at 4pm. Atlassian is an Australian company, and has generally inherited such an approach, so there's little tolerance for putting extra effort into things like adding the finishing touches to markdown parsing or improving performance (or even preventing it from regressing).

> or even preventing it from regressing

Here they are in good company with Google.

Unfortunately we’ve been piss farting around and never got round to writing a markdown parser for Aussie++.[1]

If you could do a bloke a favour and chuck up a pull request while we nip down the pub for a coupla you’d be a bloody legend.

Alright piss off now mate.

[1]https://aussieplusplus.vercel.app/

Ah, they systematically eschewed quality and engineering from their development mindset. I remember their gaslight routine whenever a proposal was made: “oh we should never divert from the 80/20 rule and whenever you work on a 20% feature, you are morally stealing from the remaining 80% of the customers. Shame on you!”

It does explain it though? Not everyone who uses Atlassian products use markdown, and I'm pretty confident that the biggest users of Jira aren't software engineers so why would they invest time and effort there?

I wonder where you get your confidence. In my experience as a software engineer in the Bay Area for 25 years, every company I've worked at (all medium to large either ISVs or internet companies) used Jira and at every one of those companies Jira was used most heavily by software engineers.

> In my experience as a software engineer > every one of those companies Jira was used most heavily by software engineers.

You don't see the correlation?

Anecdote for anecdote, I've mostly seen Jira used as a help desk tool. Back when I was in school, the professors used it to assign students to classes.

I agree these are issues

But having a jquery frontend experience with a single-threaded backend system doesn't do it any favours ;)

Is this true?

It certainly feels like it, even though it might not be technically true

The biggest issue, in my experience, has always been its performance. Perhaps I have only worked in organisations that have completely misconfigured their Jira instances or the servers are underpowered, but even with the Atlassian Cloud, I am used to waiting 10 seconds to move a ticket from one column to another. Or add a ticket to the backlog, click the backlog, ticket isn't there yet, refresh the backlog, it's there. Add a ticket to the sprint, click the sprint view, ticket isn't there. Refresh the sprint view, it's there. This sh*t. Every day. Is driving me insane.

I don't want the perfect tool, just one that isn't horrendous.

Yes to this, the performance is terrible and the UI/UX is extremely janky.

There is a lot of fault on the companies who are implementing bad configurations and multiple setups for different teams definitely adds to the complexity. To have a 'lite/light' stripped down version which is purely functional and not bloated with drag and drop events etc would be a really nice to have.

Absolutely. I worked with a lot of different tools and Jira is as good as any other project management tool. But it just didn’t feel as responsive as, for example, Linear.

Asana was just as bad as Jira in terms of performance, with the added feeling that somehow something was always happening in the background…

I agree. Most of the workflow jank could be forgiven if I didn't need to wait double-digit second loads frequently.

100% this. The worst software in the world could be forgiven if it were fast. Ours was self-hosted, but it's depressing to hear that the cloud version isn't much better.

I took a look at this a few years ago when considering a tool. Back then it turned out every button on a ticket needed to query the server as to whether it had permission to show. Just a terrible architecture.

We went with Asana. I miss the ability to create epics and do proper sprints, but at least the things load when you click on them.

I used to be a pretty big Atlassian fanboy. I'd default to most of their tools when they were available.

Before the new UI came around in ~2017 it performed pretty well and if you were judicious with customization it was easy to use. Everyone knows Jira so it was easy to get new people started with it. Then the redesign came out.

I opted in for a bit when it was in Alpha but bailed because I had trouble getting my job done in trivial ways. I'm normally pretty accepting and friendly to new UIs, even if its rough at first. I generally accept that I won't like most at first because it disrupts my workflow in the short term. Usually once I relearn the project its for the best. Not with this one. It's just so damn slow. It's terrible.

I'm not in a position where I pick our project management/documentation tooling anymore, but if I was I don't know what I'd pick. It used to be that I wouldn't think twice, now Jira isn't seriously in the running anymore. I think notion has beaten out confluence even if I'm still not in love with it.

> Perhaps I have only worked in organisations that have completely misconfigured their Jira instances or the servers are underpowered, but even with the Atlassian Cloud, I am used to waiting 10 seconds to move a ticket from one column to another.

There must be some sort of misconfiguration going on here, as I never have this experience in Jira Cloud. Your opinion is a common one so I'm not discounting it, but with "New Jira" as I call it (the Team-based projects), this never happens to me.

But in general, I agree that Atlassian should primarily focus on performance fixes, it is by far the most common complaint.

Performance is vastly improved in last few years. Until 2020, Jira Cloud was really slow.

Atlassian changed their strategic focus from on-premise to cloud, and they are making lots of improvements, including performance.

Yeah I agree with the problem description. I've seen several times Jira becoming co-opted into a sort of potemkin village where official progress is reported for customers/nervous bosses/reports upstairs, where every wording is carefully chosen as to not raise questions and sometimes tasks and progress is invented to create the appearance of smooth operations; meanwhile the need for actual tracking and planning is done offline on post-its or over email, away from prying eyes.

Seems like you are describing a agile burndown chart? Soooner or later the ant hill learns to report progress to make the line smooth via telepatic cooperation.

That's one of the additional usages, along with various progress reports, planning for management, time reporting, cost reporting, a support ticket system for the customers, etc..

Whenever people tell me they hate JIRA, what they are usually saying is they hate the process their company uses.

Could JIRA be faster, easier, etc...? Sure. But, I have tried many products to run agile/scrum teams and haven't found anything that gives the flexibility and options that JIRA has.

Ignoring the annoyances of Jira-style project management, here's some things I hate about Jira (cloud, on Firefox on Linux):

- the keyboard hotkeys aren't customisable, and often fire when I'm using alt+numbers to switch tabs, so when I come back to the Jira tab it's on some report page I don't care about

- sometimes the content won't render when switching pages, requiring a full refresh. It's difficult to tell whether it's just being slow to load, or it's gotten itself stuck. Sometimes I sit there for a few seconds like an idiot until I remember to hit refresh

- there's pretty poor support for ticket templates as far as I can tell. My company's method uses a confluence page with a table with the templates, then uses the bulk "create Jira ticket" option. But this edits the wiki page for some reason, which you need to revert. They're probably expecting you to duplicate a whole template page before generating, but the editing part could be an option in the generator wizard. With this method there's no way to go back and amend the auto-generated tickets' titles and descriptions etc. You're stuck with manually editing all of them along with the template. Surely templates are a common enough use case that warrant a dedicated workflow?

Jira is awfully slow though, saying "it could be faster" is an understatement.

The "better Jira" that I dream of is simply Jira but faster and with a better UI, I don't have issues with the underlying process

Agreed. Jira is great, but only if you have an angry tyrant at the helm managing it.

Its too flexible, if you allow people do what they want they'll have no structure at all, and you end up with disasters like a bunch custom "priority" field which are the exact same as the regular priority field except it just has different variations on "low", "medium", "high".

For my team I use basically none of Jiras features. I have a simple kanban board with 7 steps, and encourage my team to use it as a ships log. No story points or sprints or any of that stuff, the only hard requirement is that in order to close a ticket you have to write a paragraph about what was changed or attach an email to the Jira where you did the same but with a client.

> The first problem is that everyone, even in the same team or org, needs something different from it.

Big yes to this. One of the things I noticed at a client that was using it, and growing, was that multiple people not directly involved in development had a lot of visibility in to developer-focused boards. Those folks were using numbers and info we were recording, taking them largely out of context, and making strategic decisions from those.

One of my big bug bears is 'story points'. In general, I don't like them - the effort involved in accurately getting them "right" usually takes longer than just doing some of the work (not always, but a non-trivial number greater than 0).

Over time, our 'story points' and 'velocity' numbers came to mean a lot of different things to a lot of other people. We had 5 different parties who would routinely check those numbers, and often interject their own questions, call for more meetings, etc. And 99% of it was just... useless. After more talking, I'm realizing that parties A, B, C, D and E all are using the same number (story points in this case) for different purposes, sometimes vastly different.

To counter some people getting upset at seeing certain numbers go up or down too much (or too fast or too slow), sometimes numbers would be changed midway through a sprint. And, sometimes things would be added or removed from tickets mid sprint. These may be unavoidable in some cases - I get it - but the changes weren't at all related to helping the front-line workers get work done. The changes were done to make someone's sprint report numbers acceptable to someone else who asked for these reports. Neither of these parties were ever in meetings with any of us.

In the spirit of cooperation, I suggested we add some more custom fields to track the actual numbers they wanted to track (one of the things Jira does well is letting you add more data collection points). Rather than overload and use one piece of data for multiple purposes (which not everyone was aware of), why not just capture more data, to get more accurate/complete data? "Too confusing. That's too much work for you all". What they meant was "I don't know how to make new reports with this info, and I couldn't compare current data historically against old data, so we'll just keep doing this half-assed thing".

> As a result Jira becomes a proxy for all the things going wrong with your daily work and a problem of its own.

And It became that willingly, because Atlassian understood that their customer wasn't devs or PMs, but managers and corporate procurement people. They fully deserves to be on the hook for their product.

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.

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.

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...

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.

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.

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.

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.

> 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 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'd be giving up custom workflows

That’s the value prop

Value prop:

- It's not Jira

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.

Having spent 7 years now building https://www.shortcut.com/ it's very clear to me that at a certain point in the life-cycle of many organizations a bunch of people get hired who can only "think in Jira" and the vast majority of feature requests are attempts to get us to add whatever feature(s) they love using.

Conversations about why it's bad for developers or product managers or attempts to show them how to get the same value in another way often fall on deaf ears (or don't happen at all) because it's the only way that they know how to work.

One of the key indicators that this is happening is when people start saying things like "this can't do Agile because it doesn't have PET_FEATURE"

Jira isn't just software, it's a way of working that's become the de facto standard, and it's hard to get out of that box for a lot of people.

For what it's worth, thank you for fighting this fight. Shortcut has been a fantastic tool for us as a direct result of it doing things differently and more naturally. Please don't change that!

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 ...)

I'm not sure how I feel about this. On one hand, I love having an open source option. On the other hand, this is a total rip-off of Linear.app. Even the website is a copy-paste of Linear.app. A bit shocking. And for the record, Linear.app is amazing and a fantastic alternative to Jira.

Yeah, the resemblance is too strong to pass off as coincidence.

We greatly appreciate the meticulous design and user-friendly approach taken by Linear. Their work serves as a true inspiration to us. However, Plane have implemented all the concepts of Linear in a simpler terminology, making it more accessible to a wider range of users. Additionally, we are proud to make Plane an open-source project, which fosters collaboration within the community.

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?

Indeed it is a shame that they still a thing.

Damn so many negative comments here. I think it looks decent, and will probably try it out, paying $10/user/month for something as simple as an issue tracker is annoying. I get that bigger organizations have more feature requirements, but for many companies, we just need a simple issue tracker that's not jira (very biased against jira from my experience, but it's probably gotten better)

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.

More at https://www.atlassian.com/licensing/purchase-licensing#trial... under the faq question about non-profit pricing…

unfortunately, we are a buddhist organization so we do not qualify.

Check out Youtrack - not open source, but free if you have 10 or fewer users.

we are trying to work with ~35 volunteers for this purpose, but i will check it out nonetheless.

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.

Now this extensibility is what I’m interested in, as I’m working in a project which needs front end extensibility and have no idea where to start!

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".

Check out Taiga: https://www.taiga.io/

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?

thanks! looks like it's also open source as well.

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.

What's the differences between Plane and Tagia? (I actually came to think about Tagia me too when I saw this HN about Plane)

Do you know if it integrates with GitHub pull-requests?

You can do a lot on free ClickUp

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)

I've used Redmine although with just 2 users: https://www.redmine.org/projects/redmine/wiki

The per-project wiki feature is useful for documentation.

I always liked how Redmine has a tree of projects, rather than just a list.

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.

I used to use Redmine at a company I worked for several years ago. There was probably about 20 of us in total. It worked well.

Try a stack like this :

Zammad + Taiga.io|Redmine + Growi|Xwiki + Rocket.chat

Try GitLab with all project features disabled except the issue tracker. It works quite well & simple Kanban workflows are super easy to setup.

Edit: in the spirit of the thread, also try Plane.

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].

[1] https://www.tuleap.org/

[2] https://docs.tuleap.org/administration-guide/users-managemen...

Please build a startup on this. I don't want to run a Jira alternative myself. I'll pay you to do it for me.

Edit: looks like you do [1]! Perfect! I'll sign up shortly and give it a spin.

[1] https://plane.so

thanks echelon, we are working hard to make it happen in a more simple and extensible way. Also Open source :)

Beware its open core https://github.com/makeplane/plane/issues/1171

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.

"Alternative to JIRA" makes me cringe. Why would you put the most hated brand of all issue trackers in your pitch line?

It's also the most widely used of all issue trackers.

That makes it even worse!

That was my first thought as well. So glad someone else said it.

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?

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.

I remember using JIRA like 12 years ago, as a developer. We had a big "issues" list. It was a plain table, really easy to scan and see progress.

Ten+ years later I had to use Jira in another company and now it's all like expanding panels, sidebars, constantly navigating to different views. I couldnt get a simple straightforward list of issues, or I could only see things assigned to me as opposed to see the progress of the team in a straightforward table...

At the only place I’ve worked where they used Jira, only the product managers and business people used it. Devs worked from stories printed on cards. The cards would get passed around until completed, the manager would then update Jira. The advantage I guess is that Jira had a smaller audience so could be better configured for what the business wanted from it, and fewer people had to learn how to use it.

Printed as in physically printed? That's kinda neat.

The problem is not Jira the software, but what corporate people are doing with it.

No, you're not "agile" just because you have scrum sprints in Jira.

I tried setting this up on my homelab via docker. Not only did it take ages to build, I found it really difficult to run it behind an already configured nginx instance, it seemed set on running its own one. There's an open ticket on the repo to improved the docker setup experience, I'll definitely be checking this out in a few months once its all be streamlined.

It seems ok with podman but I can never login using the default credentials. Build time was indeed pretty long as well, and throwing all kinds of errors. I think if you set it up with an IP address, it doesn't run an nginx container to front the whole thing.

Probably the best feature of Linear is realtime sync, that is also what makes it feel so good to use (it writes to memory first so everything is instant). This seems like it doesn't have that, so it lacks a pretty big selling point.

Plane will also support Real-time, shipping soon :)

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!

> Open Source JIRA [...] in the simplest way possible

Mmh.

I like that it's opensource, that way product owners can become even more inventive with great ways of making a process cumbersome

IMO Jira is not the problem. It is the place where other organizational problems become visible.

If the org has a very strict form-filling culture, your Jira tickets will be full of fields to fill for no reason. If no one is valuing documentation, the documents will be outdated or spread randomly. Personally, with the right culture I do not see the problem with Jira, and with the wrong culture Jira can be slog.

How widespread is Ctrl + K -> insert URL?? Because using it for something else could cause confusion (already encountered on other platforms).

I'm pretty sure that's the cross browser shortcut for "search with default search engine". At least on the browsers I usually encounter it is.

These types of shortcut key overrides are why I've got them disabled in my browser by default.

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.

I definitely use it, and you're right that's going to be confusing. But maybe worth it..

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).

Very nice! Good job to the team - looks great. Crazy how you can jump into so many codebases & find React/Next/Tailwind.

How do you manage the coherence of the entirety of the tickets? E.g. how do you make sure that the tasks of tickets don't overlap or that there is more than one ticket for a task?

*edit: For me, backlog views are not enough to structure tickets in a meaningful way. Does Plane have a view to fluidly manage all open tickets?

I don't know how Plane is but I know very well how Jira is and it definitely needs a viable alternative.

You should give Plane a try then. It is as simple as it can get.

How is it different from all the other open-source issue trackers and project managers? Taiga.io, Open project, Focalboard, Redmine, etc

Those don't market themselves as similar to Jira, but that's not exactly a feature, so what are the differences in practice?

Hey, Our philosophy behind Plane is based on the concept of "Tasks meets Method." We have specifically designed this product to accommodate various project management practices such as Agile or Waterfall, allowing you to seamlessly implement the framework of your choice. The core idea behind Plane is to provide a solution that is both simple to use and highly extensible. Unlike other tools such as Focalboard, which solely focuses on Kanban, or Taiga, which strictly adheres to Agile principles, and Redmine, which serves as a more general project management tool, Plane aims to offer a versatile platform that combines simplicity with flexibility.

It's hard to parse this marketing speak, you are better at specific frameworks than the mono-framework tools, and a better general tool than general tools? But specifically, how?

Has anyone had a play with this and know whether it supports multiple different issue types and/or tiered issues (parent/child-level1/child-level2)?

Hey, we do have a feature of nested issues as part of Plane. You can go n-levels. You can have different type of issues via labelling.

Thanks, our use-case is requirements management and n-level support is perfect.

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

Are there mobile clients for Android and/or iOS?

It seems, over an extended period of development, any enterprise software tends to become equally hated:)

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.

Im glad there is finally an open source app with a UI that has more white space than content.

Spamming description with emoji is certainly one way to show a project is serious...

It seems to have no way to define own workflows. This is no alternative to Jira.

Now suffering free of charge

This looks nice. I will have a look. Meanwhile, does it have a Gantt view?

Looks like they just announced Gantt on the changelog: https://plane.so/changelog

Looks great, our team will be trying it out next month

mmh, on ipad i cant add an new issue. my issues > add issue. enter title/desc, click add issue. issue is not saved, all fields blank

Plans: Plane Free - Free forever

Forever, are you sure about that?

The plane free plan is ;)

I just want a simple customisable ghant chart

Plane's Gantt Chart component is completely built from scratch and is open-source. Still in early stages, but we expect a stable version by mid-june.

https://github.com/makeplane/plane/tree/develop/apps/app/com...

inb4 . they use Discord and Docker, I will not use it

Discord I understand, but Docker?

What's the tl;dr comparison with Linear?

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.

Can you compare it with Height too?

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.

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.

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.

for jira (and I assume many other similar products), it is definitely possible

Why would you want to do that? I personally hate those “stale issue” bots on GitHub, and this sounds like the same.

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.

You're assuming someone would fine the old bug from 2 years ago - it is easier to just create a new one.

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.

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.

It's an open source project.

PRs would probably be welcomed.

And a pony. They must provide a complimentary pony. An Andalusian...I wouldn't be caught dead on some common draft horse. Also a stable.

It's weird that the landing page has "Joe" and "Leo" (uncommon names in India), as placeholder users, but the authors are from India.

It is weird to hight this as feedback. Choosing very common names for a product intended for a global audience. How is that weird?

It is just weird to me that using those names was perceived as a necessary step.

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

Why not?

Also you could use "Joe" and "Pedro" instead. To me it seems even more global.

We used Joe and Pedro on some of our screenshots. Discussion is all about that :)

Valid. I get your point.

Reply on news.ycombinator.com