To me, Oodo looks like the preferable option feature-wise. But if we want to go strictly open-source, then Taiga looks like an acceptable alternative. However, I’m more confident in Odoo’s long-term health as a product than Taiga’s (given their history).
the latest update in this saga is a short (re)discovery into Taiga and Tenzu: discovery doc.
TL;DR: Taiga is in the same place feature-wise as when we did a discovery on it back in late 2022. Taiga is not very maintained now, since active development continued with Tenzu, the successor. However, Tenzu is still in early development and has less features than Taiga.
To consider going this route, we would need to evaluate:
- Which to use as a base: Taiga (more mature) or Tenzu (actively developed).
- Whether it’s worth spending the many hours development to build it into what we are looking for.
Another alternative may be to rework our workflows and/or consider using multiple tools instead of a single Jira replacement. Our workflows are closely tied to abilities and limitations of Jira, but being more open minded about workflows and replacement software may give us more options or even improve how we work.
I’m not sure what options we’ve already consider along these lines. But for example, we could use a lightweight task tool like Tenzu paired with an external time tracking and budgeting tool, and write some simple integration between the two.
Ticket: BB-10543
Since there’s no perfect option, Odoo seems way better than all the other options we’ve looked at, and I’m wondering why we haven’t tried it out yet? I know it changed from full open source to open core at some point, but the existence of the Odoo Community Association seems to indicate its health as an open source project.
According to their comparison, the open source version does not include Payroll nor Subscriptions, but I can see open source versions of both:
- GitHub - OCA/payroll: Odoo modules for payroll management
- Subscription management | The Odoo Community Association | OCA?
I suspect the same is for many other features, but I haven’t looked into it too much yet.
@braden @samuel @kshitij In the discussion on the discovery document, there has been a recent discussion of Odoo, Taiga and Tenzu. The next step decided there was to install Taiga, do the minimum of work on it to be able to use it for a concrete project, and report back:
We could do part of the scope from https://docs.google.com/spreadsheets/d/1ltgTayfYsOx_O-JqG4LDPE452-lXofwgqrsSWcnZuAA/edit?gid=0#gid=0 - the minimum to get a meaningful use of the software - and then we regroup to take the final decision on the migration? Or reconsider during the test if we run into blockers?
We have been discussing and discovering a bit in circles for some time, so we need to do something concrete - can we go forward with this plan rather than reopening the question again?
For Odoo, as mentioned in this discussion it is still potentially on the list, we are just trying to see if we can adopt a fully open source project before trying an open core one - even with the community light forking efforts on Odoo, it would still be better to settle on a fully open source project, even if we have to contribute more features for that.
In the discussion on the discovery document, there has been a recent discussion of Odoo, Taiga and Tenzu. The next step decided there was to install Taiga
Unfortunately the discussion on the Jira replacements is very fragmented. I wasn’t aware of that decision; I was just given BB-10543 to do a discovery on Taiga, to see what was new since the previous Taiga discovery in 2022. ![]()
he next step decided there was to install Taiga, do the minimum of work on it to be able to use it for a concrete project, and report back:
@antoviaque @braden @kshitij Given the significant gaps coming to Falcon (Changing how Falcon works). One idea is to work on this project (1) (2). Falcon could work on the Taiga implementation and test it with an active epic from Axim. What do you think?
We have been discussing and discovering a bit in circles for some time, so we need to do something concrete - can we go forward with this plan rather than reopening the question again?
Sorry, I didn’t want to make it seem like we’re reopening the discussion. I was on leave, so I asked @samuel to reevaluate the old discovery in case some of what we wanted was already implemented now. Since he learned that Taiga has seen no feature development since the last discovery, the results of that discovery still stand, but I feel it makes Taiga less viable.
Given that Taiga is in maintenance mode, it might be better to focus on Tenzu as the basis for our development efforts. It’s in more active feature development and is also entirely open source. In fact, there was a FOSDEM 2026 talk about the status and future of Tenzu, and it very much seems like the better foundation for active contributions even if it is less far along compared to Taiga.
Taiga is harder to maintain; it has a frontend codebase written in CoffeeScript, which is something even Open edX had to move away from well before MFEs. Tenzu is written in more modern TypeScript. It’s important to note that even the original authors of Taiga decided to do a complete rewrite because it was getting hard to maintain.
I think the fully open-source, no-lock-in mindset that BIRU, the developers behind Tenzu have is also a great fit for us.
One idea is to work on this project (1) (2). Falcon could work on the Taiga implementation and test it with an active epic from Axim. What do you think?
If the JIRA replacement project is something Falcon wants to take over, then I will gladly pass it on. Now it’s essentially narrowed down to Tenzu, Taiga, or Odoo.
Given that Taiga is in maintenance mode, it might be better to focus on Tenzu as the basis for our development efforts. It’s in more active feature development and is also entirely open source. In fact, there was a FOSDEM 2026 talk about the status and future of Tenzu, and it very much seems like the better foundation for active contributions even if it is less far along compared to Taiga.
@kshitij But the feature gap is much bigger with Tenzu than with Taiga, and we would need to schedule a new discovery to determine the work needed to fill that gap… Which would effectively just send us back into a discussion loop, as it looks like we could easily rediscover that Tenzu is still too early in its development, and that there is too much work to close the gap now.
We opted for trying Taiga now in part because there should be a migration path from Taiga to Tenzu when Tenzu matures. We can consider Tenzu properly at that time - but for now focus on completing the agreed next step? Which is:
do part of the scope from https://docs.google.com/spreadsheets/d/1ltgTayfYsOx_O-JqG4LDPE452-lXofwgqrsSWcnZuAA/edit?gid=0#gid=0 - the minimum to get a meaningful use of the software - and then we regroup to take the final decision on the migration? Or reconsider during the test if we run into blockers?
Again, I think we need to act now, we have been discovering & discussing for too long without doing much.
Given the significant gaps coming to Falcon (Changing how Falcon works). One idea is to work on this project (1) (2). Falcon could work on the Taiga implementation and test it with an active epic from Axim. What do you think?
Sounds good on my side too ![]()
@ChrisChV Would you take the epic?
@antoviaque Sure. It makes sense to focus on Taiga for now.
@ChrisChV Could you take up the ticket for setting up a Taiga instance??
The broader epic is SE-6252 but it might make sense to move it to Falcon.
@ChrisChV Could you take up the ticket for setting up a Taiga instance??
Sure, I can take it!
@ChrisChV Would you take the epic?
The broader epic is SE-6252 but it might make sense to move it to Falcon.
Sure, I can take the epic, even though I already have some epics assigned; @navin @rpenido Would you like to take the epic? If not, I can take it without any problem.
@ChrisChV Sure, I can take the epic!