My team tested Taiga on a small project. It did not work for us, with a half dozen users of mixed sophistication. Those of us who know our way around these kinds of tools could make it work, but also felt the problems that newer users could not resolve.
- The "Save" icon is tiny and hard to find in some layouts (right hand gutter, near the top and far away from your linear text entry flow). It's a floppy disk! Navigating away does not warn you that you have unsaved edits.
- Issues can be converted to Stories after review. Great. But there is no indication that the Issue has been converted, and reporters can continue to edit Issues, and the changes are not synced to the new Story item. This was very confusing for some people, and created way more friction than could be reasoned away.
- Information density was OK with a small quantity of items/comments/etc, but too sparse for a confident view with large quantities.
We moved this project over to test GitHub Projects, which is an improvement but also lacking in some important (different) areas.
...
All of these tools have always sucked on some or several dimensions. It's probably impossible to not suck.
JIRA can be made to work, though I will never do so again.
Pivotal Tracker is solid but overwhelming for reporters/casual users, and requires custom code to integrate with GitHub (but API is decent).
Sometimes I miss Trac and Redmine, if only because anything that bothered me enough could be fixed in our self-hosted instance.
The problem is developers, especially open source ones, discount the value of design and user interfaces. There are often no OSS designers, because the same culture around OSS development is not there in those designer circles, so this is why you see most OSS be terrible from a user interface and experience standpoint.
I don't think it's true that OSS devs don't value design. Maybe 20 years ago there was a bit of vestigial dismissiveness. Before that, more so. However I definitely agree that the OSS culture is not as prevalent in the design world.
But I think the real issue is that UX is more work than most developers expect, and especially to iterate over time.
UX mistakes (or imperfections) are visible for all to see, and correctness is sometimes subjective. Imagine if all of our users were able, qualified, and effectively required to evaluate source code! We do some lazy/misguided/opinionated stuff too, sometimes! :)
I didn't mean to dis Taiga above. It's thoroughly functional, if not quite right for the users I was testing with. I tried Taiga because I know the other options mostly suck, and my next-step-test is not definitively better!
> I don't think it's true that OSS devs don't value design. Maybe 20 years ago there was a bit of vestigial dismissiveness.
I'm not sure, I still see this dismissiveness. Hell, open any HN thread about design and see how many will ask what designers even do all day, or talk about them as if they're "less than" developers.
Well, everybody was a web designer 20 years ago. Nowadays we've got people who are actually good at graphical and frontend design and have actually studied their discipline. My scepticism dropped a few notches the first time I got to work with some people who really knew what they are doing and saw the value they bring and how they can save a lot of time and excruciatingly bad experimentation.
Hi, Taiga Designer here!
We are aware of the kind of design issues you mentioned. But, for now, we are only solving critical issues (kind of security ones and so) on Taiga 6 because our team is focused on the design and development of the new Taiga Next (codename). We really appreciate this feedback, though, and are actively listening to the community.
I can proudly say that our team not only cares about design, but has put Design and User Experience at the center of the product development. We are designing an improved interface, with special accessible approach, and also having special care about the way space is used (information density like you said). Likewise, we know this is a critical point in terms of a project management tool.
I'm really looking forward to sharing more advances! For now, we are sharing some of them on Taiga community (https://community.taiga.io/), please feel free to post your thoughts, ideas, and feedback.
Oh I think open-source developers care about design these days, but they're focused on getting the core functionality to work and there's only that many hours in a day. I think designers are not joining open-source projects because it requires learning some other skills that might not be interesting to them, like some basic Git, build systems and a handful of unix commands. There are several sites that have designers making mock-ups and uploading showcases of their work. If there would be a way to link those two communities together, some interesting cross-pollination might happen naturally where developers can get some fresh ideas and designers don't have to produce visual designs floating in a void.
Why do designers need to know git or build the actual app? The designers I've worked with in corporate settings work in Figma, they don't touch the code at all. We have design handoffs where we ask questions about the designs and implement them in code.
Linear looks good but it's SaaS only. It doesn't feel like a good idea to pump a lot of a company's crucial data into an external system without a way to get it out and continue elsewhere (which is a problem with a lot of bug tracking and project planning software).
Hey! (Taiga CEO) Wonderful to see taiga getting some exposure on HN. We're working on a completely new Taiga codebase, codenamed TaigaNext (we'll eventually decide on a proper name). We'll open up repos and stuff very soon for those who want to mess around with code and experimental features. Of course, TaigaNext and Penpot will have a tight integration so that both the lean and design process become more fluid for teams. We are being a bit silent on the Taiga front simply because we have a ton happening on Penpot's front atm! But expect great things from Taiga in 2023!
We've been using it for about a year and it covers our needs (We don't like to rely too hard on stuff like a Kanban board but it's nice to have). Is TaigaNext self-hostable?
Just looked into the code. Frontend is stuck on Angular 1.5. How unfortunate that long lasting projects like this are stuck on a unmaintained framework because the original maintainer changed their own course of action. This is one problem of building on top of frameworks. Someone else decides when your product needs to change.
At some point, we need to stop focusing on the next shiny thing. The web ran for decades without frameworks, then it ran well with jQuery, and now many websites use outdated frameworks. But who cares if you're not the developer working on the codebase? If the age of the framework doesn't break regular navigation and native browser behaviors there's no reason to switch to a new framework unless you are working on a big increment.
Interesting. Is that for taiga next/taiga7? Or is it the legacy branch?
There's a recent update showing off new (upcoming) flows via mouse/keyboard/screen reader that emphasize their work on accessibility. I've never tried something like gitlab/github in a screen reader - so don't know how that would compare.
I don't see any problem if the framework offers all it needs to run the application. Angular was a good choice these days and you were able to build pretty performant products.
I would be on your side if that would be a new project from 2022.
I can’t say anything regarding this project or Angular. I just want to address the „you don’t need to be on a maintained/supported version, if what you need is there“.
The problem are security bug fixes, which usually are only backported to supported versions, regardless of when they were introduced.
E.g. version 1.5 introduced a vulnerability, but it’s not found until after the release of 3.1. At this time only 3.1 and 2.5 are supported. If you’re using 1.5 you need to upgrade. Most probably at the least convenient time possible.
You probably know this already. I still wanted to address it, because at one time in my life I was young and naive and thought similar to you. There might be people out there who can learn from that.
I'd say the bigger problem is having a stack that a very limited amount of people want to work on. This is true for a company where you want to hire specific people to work on your outdated stack (hard and expensive), but even more for an open source project where you need contributors willing to work on an old stack in their free time.
I agree that this is a bigger issue, but only IF you want to change the code.
My comment was more in the direction of "the project is done, deployed, and will not change anymore". Somehow software seem to be subject to weathering over time. And what seemed like a secure piece of software can become insecure over night, when someone is fuzzing it and publishes a PoC.
Angular was and is a frontend framework. "Security issues" may alter the authentication state of the frontend but the server should always check if operations are authorised.
Lets assume the server runs php or .net. Security patches are crucial to avoid eg. code injection or malicious request forgery and thus should always be applied, maybe also upgrade the runtime version if possible.
Please tell me in which scenario a frontend issue is a security issue because I'm more the backend architect, not a naive developer.
You're focused on the security of your own server, but an insecure or compromised front end can be used to leverage your site's utility or popularity to attack your end users or be used against other sites. Just read up on XSS.
Your server can remain perfectly secure and uncompromised while your front end drags your company or project's reputation through the mud.
I mentioned in my first sentence that my reply was not really regarding Angular.
But yeah, I looked it up. Here is a link to the CVEs for Angular, mainly XSS like the sibling comment explains.
I think that the problem affects a lot more the choice of front-end framewoks, specifically. Their creators don't really valuate at all backward compatibility, so it's very easy to get stuck in an older version.
They're taking about angular here, it had basically one big upgrade from angularJS(1) to angularIO(2+) and that was 6 years ago.
Your argument might be true, but angular would be an exception as it's is pretty backward compatible and even provides you with automated upgrade scripts (ng upgrade)
I never worked with Angular 1.x., but try running `npm install` on an Angular 9 project and watch the deprecation and security warnings scroll by.
I'm in the process of upgrading a complex mono-repo from Angular 9 to 15. The biggest issues are not Angular itself, but all of the other tooling built around it.
Im not surprized by this. The Angular 1.x codebase is significantly different to the 2x architecture (which is still what modern angular runs on). Also back then the ecosysten and tooling wasnt as stable as it is now. Migrating from 1.x was pretty much a big rewrite if you where doing anything remotely interesting.
The project I'm upgrading is a library used by other downstream projects. My goal was to release a working version of the library for each Angular release. However, I could never resolve this particular issue and just had to skip that version of Angular.
Another common problem I ran into - dependencies that support, for example, ng11 and ng14 but not ng12 or ng13. So your options are to skip that version of Angular, try to replace or remove the dependency, or beg the author to add support for a version of Angular that is years out of date.
And material components version 15 has a breaking change around custom themes that means either I cannot upgrade to that version, or I have to completely rewrite the entire theming functionality within my project. So yes, I can run ng update @angular/material@15 and migrate the code easily, but that doesn't mean "it just works".
To be clear, I'm not complaining about Angular, or anything else in particular here. In my case, the decisions of the original authors caused upgrading to be more difficult than it needed to be. My point is, without knowing the details of any particular project, it's easy to see how upgrading across several major versions can quickly turn into a nightmare of rewrites.
10 years ago when Taiga was relatively new, I used to browse their source code to help learn how to build a solid api using django / django-rest-framework. They built a quality piece of software from the start and it was really helpful to learn patterns by looking at their code. Eventually they slowly replaced drf with their own implementation, cool to see it worked out.
Taiga was lunched as alpha in 2014. TaigaNext codebase comes from mid 2021 and will again be used by many devs around the world as best-practices reference, for sure!
Ah ok had my timelines a bit off, so it was the year they launched in 2014 :D I just remember I somehow heard about it, maybe on HN(?), then started looking through their backend codebase and was impressed by it.
One feature in particular I learned a lot from was their permission system, which I had never built before. It helped me reason about how to build permissions into an api.
I would never describe any university as the "most agile companies in the world" (they list ASU and UW as clients). I say that as someone who is and has been a researcher at numerous fairly prestigious ones over the year.
Seconded. Actually after doing a couple of internships I learned soo much about how to do meetings, keep tracks of projects, etc. compared to academia.
Interestingly, arguably THE most agile company in the world (Spacex) probably doesn't use any ALM tools as supported by the agile industry. Maybe a backlog tool in there somewhere, but I bet their bullshit footprint is pretty light.
It looks to me like the former government of Afghanistan may have used Taiga and it was pretty important for their workflow: https://youtu.be/DWgCbUWHxMc?t=42m46s
As long as all the features are available open source, I would say it’s free. Freemium would be like Odoo, where important parts of the software, such as accounting, are missing from the open source version.
Thanks for noting the tech stack, was the first think I was curious about.
As for "freemium": as others pointed out, I'd also put it that as long as you can self-host full-fledged instance it's "free".
Having possibility to use their "cloud" instance without charge with sole limitation of maximum 15 users is "more than free" from my point of view: they are basically paying your costs for running that. Sure, it might be negligible for them in scale, but still, as long as it saves you time and hosting costs (install and maintenance), it is a value *you* receive for free.
For my own needs, I still self-host and use OpenProject which appears to be this slightly clunky and slow but overall usable Rails app (used Kanboard for more lightweight organizational tasks before that).
Haven't personally used Taiga, so can anyone comment on their impressions, maybe also compared to something like Redmine or Jira? What's good? What's annoying? What's missing?
> Once experienced people joined the team we switched to jira.
What was the benefit and the positive outcome from doing so, outside of familiarity with Jira?
Conversely, what was problematic about the idea of sticking with Taiga or another solution, what would you miss out on?
I think that every software has some shortcomings, like some people swear by Jira, others hate it, personally I can see both sides: it works, but at the same time the REST API has stuff like createmeta which you need to use for getting issue field types programmatically, except that there were breakages in the REST library between versions 8 and 9 of Jira as no data is returned even when you run those two versions with same config in parallel, though that's only applicable to their self-hostable solution which is different from their cloud solution, without getting into the licensing changes in the following years.
I'm interested what you think about exact features or qualities that each has and how they compare.
I have tried Taiga, and I love Penpot. Here is my take on tools such as Project Management, Sales CRM that are likely to be used by lot more people once you grow.
Many Startups start with lot of other nicely designed, new, and good Sales CRM. Once they grow enough and becomes big (and successful), they all go to Salesforce. So, why not just start with it. I'm not against the other tools, they are good and they do their job. I personally love Hubspot for its UX amongst others.
For Project Management, it becomes extremely difficult to convince people to move and change to another provider once people began to settle in. This is extremely hard in larger companies. I have used Jira when it was pretty bad. Recently, I checked it and it has improved a lot. It is free for unto 10-people. If your company grows, you will need to upgrade. You should always ask, "How much am I paying when I'm paying?"
This is rather personal but I would start with the idea in mind that you will one day grow to 100+ people. And thus, which one will you use and work backwards and see if it has a cheap/free version to start with. So, why not start with something like Jira, or Basecamp (single pricing for n-users), etc. etc.
Why?
Last time I tried Taiga, it was pretty limiting. Everyone else have used Jira somehow, and I remember I could make Jira sing with its SQL-ish script.
It is certainly legacy... Yet the small footprint works well for standalone ticket resolution databases, task assignment, and budget tracking. Practically speaking, one needs to consider how many staff will be on the interface at a time.
A support database to cover user issue resolutions is part of product development. Having something you know will persist for a decade gets trickier.
I recently started using Taiga for small projects. I love it for what it is, which is a project management tool that is intuitive for a developer to use. It doesn't rely on timesheets, but on task progress, which I love. I don't care how much time people spend working on a project, I just want to see a picture of where the project is at.
When I first tested Taiga, I put my own personal schedule into it. With epics for things like Christmas, tasks for chores, going out for coffee with my mom, etc. It works amazingly well, so well that I still use this test project and prefer it to my regular schedule.
I used it in a professional setting with several team members. Taiga was a good choice and we were able to be productive and deliver the project. As such it was used to make money. As opposed to hobby purposes such as self host it and organize a road trip.
It was also stable, we encountered no bugs and the solution did not get in our way in terms of user interface. It strikes a very good balance between features and simplicity.
It may be great if you look past this, but that it BLOCKS AND FLASHES THE WHOLE SCREEN while loading ANYTHING makes it impossible for me to use or recommend to anyone until this is resolved, it's so irritating.
No other software does this for very good reasons. What were they thinking?!
Interesting, we used Taiga long time ago (5 years?) and honestly it was too simple to what we needed. The UI was poor and the whole application was slow in general. Glad to see they’re still pushing the project forward though, every competition is healthy.
Is there any plan to support mobile devices? (or are there any mobile options already). I've noticed that for many personal software (note-taking, todo, etc), phone apps work better than their desktop counterparts.
I self host my own projects on Redmine but among all the tools that I had to use with my customers I like Kanbanize because the team could see the activities, open the cards, comment, move them to different columns. For one hundred open cards I prefer that to the list in Redmine. However we had many hundreds of open cards in a large backlog and a person spending a significant amount of time on keeping the project in a reasonable shape.
The anime tracker came AFTER this project management tool. Taiga.io is from 2014, Taiga.moe is from 2015. At least those are the earliest presence of the two I could find.
Taiga is a category of boreal forests. Common words are bound to create collision, unless they share an industry there's not really any issue with that.
Why don't PageUp and PageDown work on this website? And why would I consider a tool that breaks a UI tenet in the first second of interaction with its marketing materials?
It works for me too, but to answer your question, if it was actually not working:
> Why is 1 small UI mistake is enough to put you off an entire product?
Because removing the page-up/down functionality requires extra work. If the developer is performing extra work in order to make the UI worse, then their UI decisions in general are likely to be equally crap.
> Because removing the page-up/down functionality requires extra work.
100% this
Can someone PLEASE explain to me why front-end devs go out of their way to DISABLE features?
Scrolling works fine. Having multiple ways to scroll is user-friendly and adds accessibility. Someone please explain to me why a dev is going to go "You know, I don't use Page Down/Page Up to scroll, so I'm going to spend time hooking into the Page Down/Page Up key presses so they can be thrown out and disable scrolling through those keys".
EDIT: Page Up/Down work fine for me on that page btw. Using Chrome on a MacBook Pro.
- The "Save" icon is tiny and hard to find in some layouts (right hand gutter, near the top and far away from your linear text entry flow). It's a floppy disk! Navigating away does not warn you that you have unsaved edits.
- Issues can be converted to Stories after review. Great. But there is no indication that the Issue has been converted, and reporters can continue to edit Issues, and the changes are not synced to the new Story item. This was very confusing for some people, and created way more friction than could be reasoned away.
- Information density was OK with a small quantity of items/comments/etc, but too sparse for a confident view with large quantities.
We moved this project over to test GitHub Projects, which is an improvement but also lacking in some important (different) areas.
...
All of these tools have always sucked on some or several dimensions. It's probably impossible to not suck.
JIRA can be made to work, though I will never do so again.
Pivotal Tracker is solid but overwhelming for reporters/casual users, and requires custom code to integrate with GitHub (but API is decent).
Sometimes I miss Trac and Redmine, if only because anything that bothered me enough could be fixed in our self-hosted instance.