Show HN: Tara – A smart and free alternative to Jira

Every project management software will have some reasonable defaults that can get you started in no time.

The problem is that every company (and certainly any company with more than a handful of employees), at some point, will want to adjust the tool to their use case and that's where the complexity comes in. If you can't adjust things like statuses and workflows, then you'll have issues with adoption.

All the best, this is an incredibly crowded and competitive scene.

Maybe it's just me, but maybe not.

So I'm glad that Jira doesn't force its 'release cycle' shenanigans on me. Like with git, not being opinionated is the road to success.

These are some questions potential buyers will have, specially if they are transitioning from a tool like JIRA and related suite of tools. It might be a good idea to capture this on the homepage.

First, every project has three levers: budget, timeliness, features. Choose two. So it's not about not trusting the development team. It's about understanding the tradeoffs and how the delivery date will be affected.

Second, how well can you predict what you can achieve as a developer in one day vs one hundred days? The estimate for the former is more reliable. Likewise the estimate of what you can achieve is more reliable in a one week sprint than a two week sprint. Being able to break fully deployable commits into smaller chunks (up to three days coding time) is a skill that gets better with practice. But sometimes you just don't know how long something will take because it needs breaking down and investigating. One week sprints are ideal for timeboxing investigations; here the output isn't software but discrete software tasks that fit in a one week sprint.

Ultimately it's not about trust, it's about accountability and predictability. Sprint planning tools when used appropriately don't constrain engineers, but rather highlight the truth of how things are going.

I'm not against these tools in theory (though Jira is a bit convoluted and overly complex for most simple projects) but I am against how they're widely adopted and abused in practice by businesses to enable terrible internal development cultures or perverse development strategies.

These are the types of tools that when abused, lead to swaths of developers working 50, 60, 70+ hour weeks and burning out. I'd say they're more frequently abused than they are used as aides.

At some point I realized that there’s just no stopping enterprise from going to use Jira, so it’s better to work around it.

https://treenga.com/

I wonder if I’m the only one.

Weird, that's not my experience. I use the markdown exclusively, creating, editing, or commenting.

Jira is an Enterprise product which means it is designed to tick every feature checkbox any company could ever wish for. It integrates with whatever (Enterprise) ecosystem is around it.

Tara sounds like "once you have outgrown Trello".

Apparently Atlassian was aware that most customers didn't need all of that so these days they are rolling out 'next gen' projects where one of the incentives was apparently to expose less configuration and make things less complex. The setup of a such a project is now a couple of clicks and the defaults seem pretty sane.

- We've done exactly this for Github <> Tara. We have a bi-directional sync with Github issues, and active issues are converted into tasks in Tara. Basically, if a user wanted to, they could just use Tara as a Github issue tracker.

- We wanted to start with Github, then work our way through more git/source control platforms, and then move to Jira. Interestingly, structuring incoming data from Jira requires a few months of work on data models IF we don't want the user to spend a ton of time labelling. Jira's data structure can be a hot mess to deal with.

- If the sync took a day or even a week of configuration, would you find it worth your time to invest and go through that? Or would yo expect the sync to work instantaneously (like Github <> Tara).

- What would be your expectations on mapping for histories?

The "best" sound system is worthless if the acoustics of the room it is in aren't upto it.

I am working on SaaS solution in different area. We would LOVE to sell our approach to the problem but then you start getting big customers...

Guess what, each one of them wants this changed that different color, "tasks" should be named "todos" or whatever. Then everything has to have customization options because next customer contact changes mind and the other one is leaving company.

For now our sales reps do loads of configuration for those big customers, but yeah you have to have big bucks to have sales rep do config tailored for you.

This is my biggest peeve. Every place you have other stuff related to a project, whether it's Trello, Jira, Google Drive, O365, Miro, Confluence, Figma, Travis, CodeClimate, etc etc etc, it's just another ever-increasing set of things to try to keep in sync and up to date.

It makes onboarding new members way more difficult and make everything slower, more frustrating and more error-prone.

And I can certify that Youtrack is ridiculously configurable. As in "execute arbitrary code when a ticket is updated" configurable.

Both of these features are maybe a bit too powerful (especially together), but they do enable any particular workflow you want.

Plus, their writeup on imagined vs discovered tasks and how Jira et al give false sense of control when creating tickets upfront is also illuminating: https://basecamp.com/shapeup/3.4-chapter-12

Tickets are for people not machines, they’re used to communicate with the team/PM. All the information in the ticket comes from people (usually developers) anyway. There’s no way for a machine to know if the content of a PR truly represents what the ticket asked for or what the actual status of the ticket is.

I think the only time I’ve ever used kanban in the original form was in college robotics but my understanding is that these tools are supposed to replace sticky notes.

In our setup, after a PR is merged in Github, the ticket automatically moves to the next “step”, in our case “Ready for QA”.

Beyond that there are automation workflows that accomplish much of what you are asking for here, the issue is that these are complex tools/flows that require a lot of up-front work and continuous maintenance which might not be worthwhile for all teams.

It's like a Git client. Sure, you can do it right from the commandline, but some people want something a little different-- and that's why you get clients like GitKraken with different ways of visualizing things.

Paid plans may include functionality for enterprise teams, full fledged integrations and/or smart features such as automated sprint management.

As for Github auth- that's coming!

Frankly- RN we're more optimized for smaller teams. We lack the admin/user control and SAML functionality that Jira has for larger teams. It should be interesting to see if new teams about to on-board Jira cloud find the heavy config and long load times annoying and consider making the switch.

Majority of teams (for now) switch from Notion for sprints, Trello or Asana.

What's your current Theory of Change[0] for how to affect decisions at a large company? Are you simply "paying your dues" and moving up in the ranks until you've accumulated enough political capital to make unilateral changes in the working lives of your underlings? How much does your individual organizational agility[1] figure into it? Are you, rather, content to let all decisions be made by higher-ups for the rest of your career? How do you suppose your peers model change? Is there any semblance of democracy?

I am curious because project tracking tools seem representative of a whole class of stable, albeit local-optima that don't seem to change as often as they should, and as a company ages what changes are made seem to come increasingly from decision-makers far removed from the tools' impact on the Individual Contributor.

As it's been said, "ambiguity is resolved by actions of practitioners at the sharp end of the system."[2]

0. https://en.wikipedia.org/wiki/Theory_of_change

1. https://www.scaledagileframework.com/organizational-agility/

2. https://how.complexsystems.fail/

In most scenarios I run into, "Unfortunately I work at a large company which has 'standardized' on Jira" translates into "Someone set up Jira poorly and now we dislike using it". The thing is that if you replace Jira with any tool you can imagine, the statement will hold true. Jira isn't inherently a better or worse tool than most others out there.

If you're at an org where it feels like Jira is holding you back, and you don't see the org changing tools in the near future, the best thing I can recommend is to bring in an external team to show the org how to clean it up.

Feel free to ping me if you need help (info in profile)

The main benefit of using Tara is that it provides the team a much better way of plan upcoming sprints, and the system also pulls in GitHub PRs to eliminate any blindspots on PRs getting stale.

I'd encourage you to give it a go and try it out to see if it works with your teams workflows.

We feel strongly about minimizing the amount of time spent wading through tickets and updating statuses. Currently working on a few other ideas/features that are related to status changes based on source control. Stay tuned.

As for power differential, the question is how do you instill a sense of camaraderie in individual engineers, and enable managers to load sprints with actual team data vs subjective measures. We're still working on improving this front - but so far - our "home" feature has been liked by both engineers and engineering managers.

One of the biggest issues with existing PM software is that it's purpose built for singular teams, vs providing utility to cross-functional teams (e.g. engineering and growth). And it's usually overly complex with significant configuration required.

We're seeing early signs of this with requests from teams/orgs to add in marketing, growth and design teams as they need to be in the loop of releases and the overall SDLC.

We will be bringing our ML models back into the product for predictions over time. For now, we're really focusing on workflow and design as a platform.

- Initially our hypothesis was we could build data models that automatically suggested a specification or tasks based on certain criteria the user identified (for e.g. iOS app for video based calling). - The system would suggest programming languages, frameworks and a set of tasks based on the criteria - User would immediately reject the suggestions/predictions outright (even if they were based collectively on data from stack overflow and other platforms). This would be due to a number of reasons: 1) Didn't trust the ML models to make the right predictions 2) The predictions were their first interaction with the platform.

As a result- we went back to the drawing board- and realized that to build a true "smart" project management system, we would need to start with intuitive workflows, and pepper in predictions over time based on usage and a team's actual stats. The AI tld stuck, plus we're planning on bringing the ML models to our public version soon. TBD.

We also plan on using NLP for automatic task connect to Git repos/PRs/commits and ML for predictions around effort estimates. But - we're still some time away from the open beta on making that a reality.

P.S. We recently acquired the tara.com domain which took 2 years of negotiations. A story for another time.