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.
Plane: Open-Source Alternative to Jira
181–190 of 238 posts
Re: Plane: Open-Source Alternative to Jira
#182Earlier quoted context omitted.
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 ther…
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…
Re: Plane: Open-Source Alternative to Jira
#183Re: Plane: Open-Source Alternative to Jira
#184Earlier quoted context omitted.
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 customizab…
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 eff…
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,...)
Re: Plane: Open-Source Alternative to Jira
#185The 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 simila…
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 do…
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.
Re: Plane: Open-Source Alternative to Jira
#186Earlier quoted context omitted.
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.
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.
Re: Plane: Open-Source Alternative to Jira
#187I 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…
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 customizab…
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.
Re: Plane: Open-Source Alternative to Jira
#188At 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.
Re: Plane: Open-Source Alternative to Jira
#189The 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 simila…
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 ther…
I agree. Most of the workflow jank could be forgiven if I didn't need to wait double-digit second loads frequently.
Re: Plane: Open-Source Alternative to Jira
#190The 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 simila…
> 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".