Cannot be closed source unless the maintainer dual licenses and stops making OS (assuming a single maintainer or group that all agree, or that other contributors have signed a relevant copyright waiver).
(though what has already been released can't be retracted)
It has that in common with essentially all other open source license. And it only extends to the version given to you under the license. The copyright holder(s) retain the right to change their mind. Which is a reason AGPL v3 is popular with companies that are looking to sell commercial licenses for their software. There are quite a few startups out there that attempted to keep control whose primary business model is providing a way out from the many restrictions the AGPL v3 imposes on users by offering a commercial license.
In this case, it looks like Plane is not requiring copyright transfers. So that cuts off the practicality of them ever re-licensing their software (commercially or otherwise). That's a good thing as it means it is indeed not likely the license will ever change. The bad thing is that it would be hard to build a company around this project. The AGPLv3 is just very strict about having to open source any and all bundled features and imposes a lot of restrictions and requirements.
What if a project has a plugin architecture and plugins are compiled files that can be dropped in at runtime? Those plugins can be any license then, is it not?
Plug-ins are generally considered a derived work, if directly written to use a specific API. You would need to build a module that works for many different systems and only uses the Plane APIs as a shim.
Even then, the shim might be argued to be infected, and thus the rest of the module too. In that case, you still could be facing an expensive and risky lawsuit, because I don’t think there are any precedents to predict how those winds will blow.
No. Those plugins call functions from AGPL's codebase and they are designed only to be combined with AGPL's work into a larger work, so they are derivative works.
But there is a chance that CSS and svg icons are not required to be GPL.
My opinion based on feature and screenshots is that the UX is as shitty as Jira.
The nightmare with Jira is this product manager obsession with kaban boards that become overwhelmed once your project become serious.
Snark all you want, but that's this person's experience and it's worth considering why that is the case. I'd wager they've been a victim of productivity theatre, with management saying "we need to be agile! make it so everyone -- your job depends on it!". Then, they may even hire an experienced agile manager but (for whatever reason) give them no chance to spend time and effort properly training everyone involved in how to work differently and to use the tools effectively, and how to communicate the "burn-down rate" to the users every time-period so that their expectations may be set correctly. Combine this with the attitude of many "I'll raise it as a ticket, then I'll have something official with which to chase the developers", and it's perhaps easier to see how things can become chaotic.
Perhaps you've been fortunate enough to be employed where these things are managed better than my hypothetical scenario above, but my experience that is the exception, not the rule, so it's not surprising that people can become fatigued.
My comment actually came from a place of empathy. With this comment though, I will be openly snarky when I say that you've now contributed to the art piece.
You can use Jira just fine without Kanban boards. That's really the beauty and the curse of Jira, it can be pretty much anything you want it to. To truly compete with Jira you need a level of flexibility that almost guarantees that your product will suck to.
If you run Jira, Confluence and Bitbucket, the level of integration you can achieve is pretty unmatched. The cost: You need to buy the data center edition, on-prem is required to get any sensible level of performance, and you need Atlassian experts on staff.
Even in list view, it goes very fast to so overwhelmed that it is unusable.
There are then usually 2 cases:
- teams have strategy like closing every issues that can't be worked on immediately. So clean board but rotten software with lots of issues buried and regularly rediscovered.
- team just letting issues list grow unmanageably and will only look at the most recent things or what arrived in the parking.
In the few different companies of different sizes that I worked, I never saw a Jira that did not become a hot mess until people start new projects or new boards when they can't bear anymore.
I find it also extremely difficult to find anything. Like you know that an issue exist but search will not help you find it easily.
Very often I have to go to Gmail to search in notifications to find back the link to an issue.
Alright, I am not denying you might be right, but it sounds like an old man yelling at cloud.
If not Kanban, what else would you propose as the 'better' solution
Honestly, the best experience I had so far was with Redmine.
It can look a little bit rough, and sure there could be lot of improvement.
But it favored efficiency against eye candy design.
It is very easy to have things organized the old way. Having projects, recursive sub-projects.
You can look at your issues at the sub sub project level or at a more global level.
You can easily have list with all the variable that matters. That you can order easily how you need:
Who's the rapporter? Who's the dev? Who's assigned to? What is the state? When was the issue discovered? In which version? Fixed with which milestone?
It is very slick, I did not feel a latency like in Jira, the screen is not filled with useless crux, only what matters fills the screen.
In a few clicks I was always able to find what I was looking for, set and identify all the affected versions and which one got the fixes.
Related: I would love to see an open source confluence alternative as well, as for issues there are many (more or less capable) options to choose from.
What I most want from a Confluence alternative, and I have a few poor ideas how this can be solved, is a way to manage stale content. The Confluence spaces I work with are dumping grounds of old, often misleading, information.
Deduplication guidance, reports on untouched content…I don’t know how to fix this, but someone surely can solve it.
Looks pretty basic but somehow complete. The first impression is good. Here's some criticism:
The first thing I look for in a issue tracker is the screen estate to write the task. I understand that some people write a list of issues in the form of short blurbs and iterate on them afterwards, but it always feels frustrating to me to having to write the title in a modal window, save and then open the issue again to be able to see a larger textarea for the description. I also see it as discouraging for people to write better descriptions for the issues they open.
The keyboard navigation is probably not complete (press P to create a project, you would still need the mouse to focus the textbox and to save the project)
On my computer it started in Dark Mode, and the experience overall was quite a bit disorientating. Also no light/mode switch icon in the header.
It is not clear to the user that you can/should use markdown.
> On my computer it started in Dark Mode, and the experience overall was quite a bit disorientating. Also no light/mode switch icon in the header.
I don't really know that you need a light/dark mode switch. It should follow your preferences. I see dark mode websites all the time, because my desktop is set to dark mode. On my Windows machine I see the same websites with the light-mode, because I did not bother to figure out how to set Windows to dark-mode.
I come to HN for high-quality discussion. If I were looking for snark and meme content I'd be on Reddit.
In this particular case, your parent made a very reasonable case that a web app could simply choose to respect the system light/dark mode and that would be enough. I happen to disagree with them, but they were sincerely contributing to the discussion.
You came along with a 4-word + emoticon + hashtag parody of what they said that was inaccurate and frankly rude. I came away from your comment not at all sure what point you were trying to make but 100% sure that your comment wasn't contributing to an interesting discussion.
Here's a possible rewrite, assuming your objection was that some computers don't support system theming:
> If you only support system themes, you're excluding a large number of older systems that don't have their own light and dark modes. A toggle wouldn't take up much space in the header and would help those users to use the mode they prefer.
I see your point - I suppose it was quite snarky. My take is (and I suspect the same as the people who upvoted my comment) that the comment was disregarding another persons feature request/preferences based because the did not match his/her own. It is an, in my experience, attitude not uncommon - and it (unfortunately) gets my blood boiling every time.
Hi, I am Aaryan, one of the maintainers at Plane. We currently have the theming settings available under the profile section, where you can set themes like light, dark, custom themes, and more. Thank you for your suggestion; we will certainly work on implementing the system preference setting and find a better placement for the theme switcher.
Hey Aaryan, I just signed up and am taking the tour, and the body copy (#737373 on #070707) is effectively unreadable while sitting outside with my MacBook Air at max brightness. (Hacker News remains easy to read in the same scenario.)
For accessibility's sake, it'd be nice if the site met WCAG Level AAA contrast ratio requirements.
Yes of course you need one, the detection is what I can call flaky at best (talking about the websites I visit, not that the tech doesn't exist) and also I know many people who only run a good chunk of websites on their actual preference, and others on the other version, I'm one of them, I only use dark mode in about 1/3 of websites where I know about the two modes.
This bothers me on almost all project management software.
What I'd love to see, is to be able to assign one person as the one "responsible" and then assign others ad-hoc when/if they work on-, review-, discuss, or co-author it.
Some software allows multiple assignees, but as the ancient management-saying goes: if everyone is responsible, no-one is. So i'd still love to have one person assigned with a special role or label.
Yeah this is an issue with my current company's use of Jira. They're super worried about tickets being "lost" so they all have to be assigned to one person, but then that means you can't tell who is actually working on something.
My previous company used Phabricator and you only assigned yourself a task when you actually started working on it. It meant anyone could work on anything - much more agile and much much better knowledge spreading and teamwork.
But I understand where my current company is coming from. You want a "person who is responsible for making sure this eventually gets done" field and a "person who is currently working on this" field.
> You want a "person who is responsible for making sure this eventually gets done" field and a "person who is currently working on this" field.
Indeed. But the last part should be plural. Because in reality multiple people work on it. A reviewer, someone who helped with the UX, the person you spoke to to get the exact business-details right, that colleague you needed to finetune the SQL, or the moment bob goes on vacation and you need to step in and take over his work.
At my work we have a couple of different roles that get involved in each ticket, so we created custom fields in Jira to assign those roles.
So each ticket gets a Primary Developer, Primary SME, etc, but might get assigned to some one else to do one small bit of work (e.g., it'll get assigned to a different developer for code review, but whoever's listed as the Primary Developer is still responsible for it).
Sure, but you can have plenty of options where there's one responsible person, but you may still want to track another person who's involved. Maybe another engineer who's paired on the project, or the PM who's taking point on it, or the QA who's testing it, or the other engineer who's reviewing it.
Having to rely on comments or assignment history to uncover that information is a bad experience.
Perhaps? But I do plenty of projects where I'm just paired with another engineer. I'm maybe taking lead, but they're sitting in on all the meetings and helping make decisions when I want someone to check my work. That may be worth noting in a ticket in case I'm busy or out of office and someone needs an answer around the project, even if they don't have a specific task they're responsible for that they'd be assigned a child ticket for.
It's also a level of precision question. At some point, having a lot of child tickets is just extra work if it's mostly just documenting something that could have been as easily documented by attaching another person's name to the parent ticket.
Is it me or does that look extremely similar to Linear, another competitor in that space?
Not in the sense of the feature set, there's only so many things you can do with an issue tracker and a kanban board, but in the sense of actual visual design (fonts, text sizes, etc.)
For potentially confused people out there: some countries/musical traditions use a do-re-mi-fa-so-la-ti(si) scale, rather than do-re-mi-fa-sol-la-si or a-b-c-d-e-f-g.
This has the interesting side effect that the word solfege (sol-fa) makes little sense.
I find the name 'plane' itself curious. As an upcoming product you make yourself quite hard to find in search engines (though "plane issue tracker" gives plane.so as first result in DDG).
- Corporate firewalls don’t like people visiting .so Somalia URLs. Wouldn’t have this problem with .com. We had to fight hard for domain reputation.
- Back in the day communication between us, our registrar, a middleman registrar in Germany, and SomaliNIC wasn’t too good. We weren’t notified of a takedown report and got DNS blocked by a bunch of ISPs offline for 8 hours. Even figuring out what happened on that one was baffling.
Why do people call things Jira alternatives that contain about 1/500th of the features? It's just a simple project management tool with a kanban board...
Because that’s that most people see Jira as. It’s easy to only use Jiras surface level features, like a Trello with a little more functionality, and not the more advanced ones.
yeah, marketing is all about using the simplest language to communicate truth relevant to the group you want to reach, not about communicating absolute truth to all comers.
Because jira's advanced features kinda suck. They have a market lock because they have been able to own the space with first mover advantage and buy their competitors.
Pretty common. Everything I've seen presented as a "Notion alternative" is nothing more than a note taking app, "Airtable alternatives" only copy the data-in-rows UI, etc.
I used to work at a company where incoming support tickets were just another jira project (FOO-123), it worked great because you could then relate the tickets to actual work items (BAR-123) and while the support tickets weren't public for obvious reasons, the work items were, so customers could easily follow the progress of the work item without having to re-contact support.
My impression was that this level of transparency was extremely appreciated by customers, even in cases where bug fixes were marked as "won't do", usually with a workaround of some kind. This in itself also becomes an invaluable knowledge base over time, not to mention all the other benefits you get from support and engineering tracking their work in the same application.
But of course, like all good things it didn't last, because the company was bought by some other company that thought it was absolutely insane to publicly admit that your software had bugs.
^ You nailed it. The only issue tracker you need today comes with your source code repo. Both github and gitlab are not only more than sufficient, they are arguably better because the stripped down natures keeps people from doing silly things like all the jira anti-patterns.
I kinda wish we could migrate completely off Jira and just start using GitLab issues instead. Unfortunately that's probably a fat chance when GitLab wants to charge us $99/month/user if we want to grant non-developers access to our GitLab. Jira is like $15/month/user.
I've had good luck with getting GitLab Issues to do an appropriate variation on Kanban, so long as I have their Scoped Labels (which seems to be in the $29/user/month Premium plan). I like the tight integration with the Git workflows, and I like not having to manage yet another SaaS.
Do some of your users need the $99 Ultimate plan, and GitLab salespeople couldn't meet you at workable pricing for your users who mostly only need to use Issues?
I don't think you can pick and choose the plans per user? We're currently using the security features of GitLab Ultimate and as far as I've understood it, that's $99/month/user for every user you need on your GitLab license.
I think enterprise software agreements can often be negotiated.
In the case of GitLab, their pricing page has the usual easy ordering buttons for each pricing tier, but the $99 tier button also has a prominent "Contact Sales" link right below the button. https://about.gitlab.com/pricing/
Once you're already paying sticker price, and have invested in using it (i.e., moving to a competitor is a lot of work), your negotiating position will be different, but the vendor can still lose the account, if customer is unhappy enough to eat the moving costs.
I strongly disagree. You can't easily have conversations about issues in Git and even if you could do you really want to have a commit for each message?
I'm aware of some systems that try to tack issue tracking onto Git in a similar way to Fossil, but they just aren't as good as a proper issue tracker.
That said, Jira is a terrible issue tracker. I do not understand how it is so bad given that it is literally its only job.
I used Phabricator for issue tracking in my previous company and it was so far ahead of Jira... It makes no sense.
Something as basic as parent/child issues is barely implemented in Jira. You can only have 2 levels of hierarchy.
You can't put a task in your sprint unless it matches the task filter for that sprint, which means you can't easily track the work of people that work on multiple projects.
You can't even put tasks from multiple projects into one sprint. Realistically you should have a single project for everything.
They haven't even got basic stuff like "refresh the page when information on it changes" working.
And that's before you even get to the core flaw of Jira which is that it encourages product managers to overcomplicate it.
But just because Jira is awful doesn't mean issue trackers in general are. Phabricator's is great. GitHub and Gitlab are basic but decent. I haven't got experience with any others but I'm sure there are great ones.
As you touched on, the major problem with Jira is actually that it does so much nobody (roughly) knows how to use it.
You get 3 levels if you include Epic (Epic > Task > Subtask).
You can set up a sprint/kanban board filter to cover multiple projects, so this does actualy gives you multiple projects per sprint.
I do agree that it's slow and doesn't update itself to reflect changes.
The two groups of people who hate Jira the most are (1) those who can't get it to work how they want it to and (2) those who have to deal with someone else's mad/broken custom workflow.
A client of mine decided to ditch Jira last year. Now what they do is use a much simpler system but with a ton of manual wrangling going on constantly. Lots of duplication across boards, most tickets are in the wrong state, nobody knows who's supposed to be handling any given task. I'm mostly trying to stay away from it.
Your theory works if there are only developers, and they are all competent. Throw the usual mix non-dev staff into the mix along with the and it's a mess.
> Both github and gitlab are not only more than sufficient, they are arguably better because the stripped down natures
I can show you plenty of repos where people do silly things with Github and Gitlab tickets in a quest to better track all the work that will never get done.
Most of my “tasks” are buggy, poorly written, feature incomplete, draft requests for code review which come with an implied contract that early feedback is welcome, but that I’ll let you know when it’s actually ready, and I promise to either make good on that or cancel the request and say why before the end of the quarter.
before this merge we operated off only github issues and never had problems with it
now we have length jira planning sessions, new meetings every 2-3 weeks on updated jira expectations, and a whole group of people whose job it is to track our jira usage and let us know if we aren't using it correctly / meeting standards
under one system we always finished work ahead of time and could actively pursue more projects
under one we are constantly behind the "estimate" for our assigned work
That's valid, but saying that a product a few developers created for FREE, and made open source so anyone could copy and change is the "wrong thing to copy" is just disrespectful.
It would be disrespectful if thats all they said, but including "it would be nice.." and "...imho" changes it to politely giving their opinion on a third party forum. If it were a show hn, or the projects own forum I might agree with you, but this is the appropriate place to give armchair opinions.
What are the unique features or approaches of Bugzilla compared to Jira? Before Jira was a thing, Redmine was (is?) very popular and often received better reviews than Bugzilla, so I was a bit surprised you mentioned Bugzilla.
They meant “linear.app”, not Jira, and “copy” instead of alternative.
There’s currency in this type of knock off. Find a well executed closed source app, clone as open source, pick an alternative pitch “the Jira killer”, then raise YC because open core is the fashionable argument.
149 comments
[ 3.3 ms ] story [ 188 ms ] threadhttps://github.com/makeplane/plane/blob/develop/LICENSE.txt
Cannot be closed source unless the maintainer dual licenses and stops making OS (assuming a single maintainer or group that all agree, or that other contributors have signed a relevant copyright waiver).
(though what has already been released can't be retracted)
This is the only relevant bit. A license can't force people to do work for free in the future.
I couldn't find any outside contribution in the repo yet, we'll see how they go.
In this case, it looks like Plane is not requiring copyright transfers. So that cuts off the practicality of them ever re-licensing their software (commercially or otherwise). That's a good thing as it means it is indeed not likely the license will ever change. The bad thing is that it would be hard to build a company around this project. The AGPLv3 is just very strict about having to open source any and all bundled features and imposes a lot of restrictions and requirements.
Even then, the shim might be argued to be infected, and thus the rest of the module too. In that case, you still could be facing an expensive and risky lawsuit, because I don’t think there are any precedents to predict how those winds will blow.
But there is a chance that CSS and svg icons are not required to be GPL.
See WordPress clarification on themes' licensing: https://wordpress.org/news/2009/07/themes-are-gpl-too/
Perhaps you've been fortunate enough to be employed where these things are managed better than my hypothetical scenario above, but my experience that is the exception, not the rule, so it's not surprising that people can become fatigued.
In our company our CIO declared everything should be agile. So now we log our hours in Jira. That's it :P supposedly that makes us agile or something.
But yeah the VP they acquired from another company to manage us is a total tool.
If you run Jira, Confluence and Bitbucket, the level of integration you can achieve is pretty unmatched. The cost: You need to buy the data center edition, on-prem is required to get any sensible level of performance, and you need Atlassian experts on staff.
In the few different companies of different sizes that I worked, I never saw a Jira that did not become a hot mess until people start new projects or new boards when they can't bear anymore.
I find it also extremely difficult to find anything. Like you know that an issue exist but search will not help you find it easily. Very often I have to go to Gmail to search in notifications to find back the link to an issue.
There's no obligation to propose a better solution when saying something sucks.
It can look a little bit rough, and sure there could be lot of improvement. But it favored efficiency against eye candy design.
It is very easy to have things organized the old way. Having projects, recursive sub-projects.
You can look at your issues at the sub sub project level or at a more global level.
You can easily have list with all the variable that matters. That you can order easily how you need: Who's the rapporter? Who's the dev? Who's assigned to? What is the state? When was the issue discovered? In which version? Fixed with which milestone?
It is very slick, I did not feel a latency like in Jira, the screen is not filled with useless crux, only what matters fills the screen. In a few clicks I was always able to find what I was looking for, set and identify all the affected versions and which one got the fixes.
Related: I would love to see an open source confluence alternative as well, as for issues there are many (more or less capable) options to choose from.
Deduplication guidance, reports on untouched content…I don’t know how to fix this, but someone surely can solve it.
I'm really impressed by the product. Seems to be a good Confluence alternative.
Looks pretty basic but somehow complete. The first impression is good. Here's some criticism:
The first thing I look for in a issue tracker is the screen estate to write the task. I understand that some people write a list of issues in the form of short blurbs and iterate on them afterwards, but it always feels frustrating to me to having to write the title in a modal window, save and then open the issue again to be able to see a larger textarea for the description. I also see it as discouraging for people to write better descriptions for the issues they open.
The keyboard navigation is probably not complete (press P to create a project, you would still need the mouse to focus the textbox and to save the project)
On my computer it started in Dark Mode, and the experience overall was quite a bit disorientating. Also no light/mode switch icon in the header.
It is not clear to the user that you can/should use markdown.
I don't really know that you need a light/dark mode switch. It should follow your preferences. I see dark mode websites all the time, because my desktop is set to dark mode. On my Windows machine I see the same websites with the light-mode, because I did not bother to figure out how to set Windows to dark-mode.
[EDIT: The Plane App ignores my preferences].
In this particular case, your parent made a very reasonable case that a web app could simply choose to respect the system light/dark mode and that would be enough. I happen to disagree with them, but they were sincerely contributing to the discussion.
You came along with a 4-word + emoticon + hashtag parody of what they said that was inaccurate and frankly rude. I came away from your comment not at all sure what point you were trying to make but 100% sure that your comment wasn't contributing to an interesting discussion.
Here's a possible rewrite, assuming your objection was that some computers don't support system theming:
> If you only support system themes, you're excluding a large number of older systems that don't have their own light and dark modes. A toggle wouldn't take up much space in the header and would help those users to use the mode they prefer.
For accessibility's sake, it'd be nice if the site met WCAG Level AAA contrast ratio requirements.
Subtasks kinda helps in Jira
What I'd love to see, is to be able to assign one person as the one "responsible" and then assign others ad-hoc when/if they work on-, review-, discuss, or co-author it.
Some software allows multiple assignees, but as the ancient management-saying goes: if everyone is responsible, no-one is. So i'd still love to have one person assigned with a special role or label.
My previous company used Phabricator and you only assigned yourself a task when you actually started working on it. It meant anyone could work on anything - much more agile and much much better knowledge spreading and teamwork.
But I understand where my current company is coming from. You want a "person who is responsible for making sure this eventually gets done" field and a "person who is currently working on this" field.
Indeed. But the last part should be plural. Because in reality multiple people work on it. A reviewer, someone who helped with the UX, the person you spoke to to get the exact business-details right, that colleague you needed to finetune the SQL, or the moment bob goes on vacation and you need to step in and take over his work.
So each ticket gets a Primary Developer, Primary SME, etc, but might get assigned to some one else to do one small bit of work (e.g., it'll get assigned to a different developer for code review, but whoever's listed as the Primary Developer is still responsible for it).
Having to rely on comments or assignment history to uncover that information is a bad experience.
It's also a level of precision question. At some point, having a lot of child tickets is just extra work if it's mostly just documenting something that could have been as easily documented by attaching another person's name to the parent ticket.
Shared responsibility is called collaboration.
Not in the sense of the feature set, there's only so many things you can do with an issue tracker and a kanban board, but in the sense of actual visual design (fonts, text sizes, etc.)
What is the story here? I'm just curious (and bored) :).
This has the interesting side effect that the word solfege (sol-fa) makes little sense.
https://en.m.wikipedia.org/wiki/Solf%C3%A8ge#Note_names
- Back in the day communication between us, our registrar, a middleman registrar in Germany, and SomaliNIC wasn’t too good. We weren’t notified of a takedown report and got DNS blocked by a bunch of ISPs offline for 8 hours. Even figuring out what happened on that one was baffling.
LOL, at least they are honest about companies doing waterfall style planning being their target audience.
You could probably do without one at all even.
My impression was that this level of transparency was extremely appreciated by customers, even in cases where bug fixes were marked as "won't do", usually with a workaround of some kind. This in itself also becomes an invaluable knowledge base over time, not to mention all the other benefits you get from support and engineering tracking their work in the same application.
But of course, like all good things it didn't last, because the company was bought by some other company that thought it was absolutely insane to publicly admit that your software had bugs.
Do some of your users need the $99 Ultimate plan, and GitLab salespeople couldn't meet you at workable pricing for your users who mostly only need to use Issues?
In the case of GitLab, their pricing page has the usual easy ordering buttons for each pricing tier, but the $99 tier button also has a prominent "Contact Sales" link right below the button. https://about.gitlab.com/pricing/
Once you're already paying sticker price, and have invested in using it (i.e., moving to a competitor is a lot of work), your negotiating position will be different, but the vendor can still lose the account, if customer is unhappy enough to eat the moving costs.
I'm aware of some systems that try to tack issue tracking onto Git in a similar way to Fossil, but they just aren't as good as a proper issue tracker.
That said, Jira is a terrible issue tracker. I do not understand how it is so bad given that it is literally its only job.
I used Phabricator for issue tracking in my previous company and it was so far ahead of Jira... It makes no sense.
Something as basic as parent/child issues is barely implemented in Jira. You can only have 2 levels of hierarchy.
You can't put a task in your sprint unless it matches the task filter for that sprint, which means you can't easily track the work of people that work on multiple projects.
You can't even put tasks from multiple projects into one sprint. Realistically you should have a single project for everything.
They haven't even got basic stuff like "refresh the page when information on it changes" working.
And that's before you even get to the core flaw of Jira which is that it encourages product managers to overcomplicate it.
But just because Jira is awful doesn't mean issue trackers in general are. Phabricator's is great. GitHub and Gitlab are basic but decent. I haven't got experience with any others but I'm sure there are great ones.
You get 3 levels if you include Epic (Epic > Task > Subtask).
You can set up a sprint/kanban board filter to cover multiple projects, so this does actualy gives you multiple projects per sprint.
I do agree that it's slow and doesn't update itself to reflect changes.
The two groups of people who hate Jira the most are (1) those who can't get it to work how they want it to and (2) those who have to deal with someone else's mad/broken custom workflow.
We appear to have four levels of grouping above "Epic", albeit none of them are even visible in our sprints.
Indeed but that's still an artificial limitation, and subtasks are not really fully featured tasks.
A client of mine decided to ditch Jira last year. Now what they do is use a much simpler system but with a ton of manual wrangling going on constantly. Lots of duplication across boards, most tickets are in the wrong state, nobody knows who's supposed to be handling any given task. I'm mostly trying to stay away from it.
Your theory works if there are only developers, and they are all competent. Throw the usual mix non-dev staff into the mix along with the and it's a mess.
I can show you plenty of repos where people do silly things with Github and Gitlab tickets in a quest to better track all the work that will never get done.
Planning schmanning!
my team just merged with another, larger team.
before this merge we operated off only github issues and never had problems with it
now we have length jira planning sessions, new meetings every 2-3 weeks on updated jira expectations, and a whole group of people whose job it is to track our jira usage and let us know if we aren't using it correctly / meeting standards
under one system we always finished work ahead of time and could actively pursue more projects
under one we are constantly behind the "estimate" for our assigned work
care to guess which is which?
Most of the times when I read some post about Jira alternatives is that they completely ignore this topic.
Or maybe just to reach someone who never used bugzilla and doesn't realize it's light-years better than jira or rally.
There’s currency in this type of knock off. Find a well executed closed source app, clone as open source, pick an alternative pitch “the Jira killer”, then raise YC because open core is the fashionable argument.