Show HN: Tara – A free Jira alternative, now with Gitlab
tara.ai
tara.ai
I'm one of the creators of Tara, and with support and feedback from the community, we've been hard at work building this v1.5 release over 24 sprints and 500+ pull requests. Several of you asked for an improved Github sync, PRs and commits tracked in tasks, alongside a Gitlab integration. We've discovered from teams, just how painful Jira and Confluence can be for tracking issues, sprints and docs. Our requirements feature has also gone through a bit of a re-design, and with Gitlab, we've also shipped commenting, workspaces and teams.
As for why we're working on this problem; we just wanted to use something fast, with minimal setup, and built-in views for Git. We just couldn't find anything designed from the ground up for development teams.
Finally, Tara AI is free for teams and developers. Our free forever plan has no limits on users, tasks or workspaces. Looking forward, we're working on predictive functionality around effort estimation, release planning and engineering analytics.
Thanks for reading!
There is also a lot of whitespace between welcome username, and the getting started copy on the page.
The home icon and the logo in the left nav do the same thing not sure if you need both.
Create task in the backlog should stand out more, I'm a PM and that is probably one of the most used options. Is there an option to add time to a task or urgency?
Hope this helps, looks like a great start.
Good point on the whitespace- will take a look.
As for creating tasks- we're thinking of a sticky area on the left (that's always on) to create tasks.
For priority- we're releasing labels in 3 weeks. You should be able to assign #P1 or priority overall on different sets of tasks. That being said- we are considering adding some form of auto recognition or NLP to suggest priority and labels automatically based on past tasks. For time, we have 3 effort options (points, hours or days), we kept it simple to create a standup view where you can see how engineers track throughout the week.
Let us know which other parts may be tedious. We have more work to do!
>We are working on functionality for teams that provides visibility and predictability in product development. Features may include automation around sprints and multi-team workflows. This will be part of our premium plan, and is where the AI comes into play.
I've also been hurt by free tools that disappear after we commit to them but since Tara did AI stuff for PM in the past maybe they already have it in the roadmap.
Basically, RN its a webhook. Once active, you can view merge requests related to a task, when synced. Over time, we should be releasing a full fledged Gitlab bi-directional sync and app (similar to our Github app here: https://github.com/marketplace/tara-ai)
Our Github app also allows you to view stale PRs that are blocking the sprint. We should have similar functionality for Gitlab over the next few wks.
I ask because this seems like the sort of thing I would look at, then shrug off because it's not all there, as I don't want to put time and energy into learning a product that will have the features I want "some day", so I'd be likely to skip out on it for now and then forget about it basically forever.
Personally, I'd much rather be shown something that feels "done" and try to integrate it then than work with someone's first pass on the implementation, and I'm concerned that others would feel the same way and you would miss out on users.
In our case, the main ask from developers is the ability to sync/connect their tasks to merge requests on Gitlab. v1 of the integration does exactly that, and additional elements will be shipped over the coming weeks as users activate the integration.
I would summarize the problems of various bugtrackers including Jira as being insufficiently “up with the times” therefore. They reflect the old modernist approach to truth. Schedules, deadlines, when was this “done”. But we know in software that really you want your source of truth of your bugtracker to basically be in the same Git repository as your code: one and the same commit needs to simultaneously close a bug as needs to properly change the source code to fix that bug, because the bug may be fixed in your “staging” codebase but that bugfix may not yet be deployed to “prod.” A reversion merged into prod as a hotfix needs to suddenly re-open the bug that we said was fixed-in-prod because now it no longer is. All of that. That's my hazy crackpot vision. :)
Given all that, there is also a great difficulty with people using workflows like GitFlow which have the same “old way of doing things” misunderstandings. It’s not that those workflows aren’t good, they are good—for SVN repositories. You apply them to a Git repository and then you have this strange tension where the workflow and the VCS are working at cross-purposes sometimes. So it's also things like GitLab's CI/CD being a file checked into Git. This sounds great until you realize that nobody is expecting postmodernism to suddenly pop up here. “How did you merge that thing into prod when all of our admins were unreachable? Admins are supposed to have to push the button.” “Well, I was really in a bind, so I did something I would have never normally done: I pushed up my own branch `fix-master`, and in that branch I changed the CI/CD file to trigger deploys to production on pushes to `fix-master` instead of `master`.” But I had to!” Git was like “hegemony? what hegemony? if `master` has power then everyone has power.” Hah.
So my question is, based on this description, I am not sure that I see you have “drunk the same Kool-aid” about Git, I am instead seeing a declaration that you want something fast-and-easy-and-supports-Git.
Which, like, is fine. I don’t want to come across as crapping on your invention with a dream that I absolutely admit is hazy and crackpot, right? You have actually done the work and I am hypothetical and I have mad respect for you and your work. But I am sharing kind of my bigger vision to ask, “do you have a bigger vision? is it different than mine, some more systematic structure?” Is Tara just an easy way to do something like Jira with Git, or do you have a fundamentally new concept in mind that you are headed towards that will change how we track issues with our software?
I think that one of the points that you raise is quite valid - that issue tracking should really be integrated into version control.
you are talking about philosophical relativism and using a philosophically progressivist bias to claim legitimacy.
at some point, Alice and Bob's linux will diverge to the point that Charlie will recognize neither as being linux, at which point there needs to be some basis for legitimacy to have a common ground, which in turn 'devolves into asking questions about power' (e.g. authority/legitimacy)
one can certainly be too fixed in ones approach, but the inverse is also true.
if bob, alice and charlie all work for an organization of people delivering 'the same linux' (whether open source/community driven or public company), what will a consumer of this 'linux' recieve when they get it?
which in turn 'devolves into asking questions about power' ..
ultimately we need to be on some same page, even if it is a bunch of post it notes on a desk and not a neatly bound hardcopy, so i wouldn't let the dualism implicit in being relativist create a false dichotomy whereby being organized at all is somehow outside of the realm of possibility.
what does your vision of 'keeping track of being on the same page' look like, if the page doesn't even need to exist to be on it?
or does so-called software 'enlightenment' require dissociating from all fixed concepts altogether? (show me the computer that will work this way and not be a magic spell, quantum included, since we are talking about 'being realistic')
I’m tying this to the notion of Git’s branching model of course, each branch being something of a slightly different perspective or reference code for the same amorphous project of Linux. What consumers receive is just that then, a perspective on the broader project, one particular snapshot with various patches and so forth. In an OOP analogy Linux is a class and they receive an instance of that class, maybe.
But yeah I think I am with you, dissociating from all fixed concepts altogether is probably not a great direction to go with this. You want some project organization and request or issue tracking. I am sorry if I sort of was suggesting that issue-tracking at all was meaningless, I definitely don’t agree with that. But I do think it instead has something to do with recognizing that the code to resolve an issue (if there is code at all, if it's not just getting closed as works-as-intended) leads to that issue having a “status” which needs to be tracked across multiple branches, and that this process is tedious and error-prone when we try to do it by hand.
Your branding is awfully similar to Atlassian. Not saying it's intentional, but considering you are pitching yourself as a Jira alternative, it would be wise to differentiate yourselves a bit more.
Specifically talking about the logo and color.
Let my introduce you to "Dotan's Blur Test": Blur your eyes a bit when looking at the two homepages so that the shapes of logos and text disappears but the colours and placement stay the same.
I cannot tell the two logos nor pages apart in the blur test. That may draw fire from Atlassian's legal team, and should probably be addressed.
> this pilot agreement ("agreement") is a legal agreement between you ("tester") and tara intelligence inc. ("company"). company is developing a software platform product offering for managing product development lifecycles ("company platform"), and this agreement governs tester's use of the company platform. by accessing or using the service or by clicking the "i accept" button, tester acknowledges that tester has reviewed and accepts this agreement.
If so, what obstacles prevent from open sourcing it? At least the the part of functionality which is declared to be free forever?
> Our free forever plan has unlimited tasks, sprints and workspaces, with no user limits.
We take privacy around your data very seriously. We're thinking about the ML training model as a "walled garden", ie recommendations are based on your past sprint activity, effort load, tasks completed during a sprint, etc. and are exclusive to your organization.
In the future, if we decided to do benchmarking (for eg quick recommendations on how companies in your industry are running sprints), we would have a double opt-in. This would mean anonymizing the data, and providing the recommendations an opt-in. Basically, very similar to how google's autocomplete email recommendations work.
I already don't trust jira too much. Unless it is self-hosted and you want to be a test data collection set for them. Then it is not worth it.
> How will you stay in business?
"We are working on functionality for teams that provides visibility and predictability in product development. Features may include automation around sprints and multi-team workflows. This will be part of our premium plan, and is where the AI comes into play."
/s
Open-source is great. One time purchase price is great for products that don't require maintenance. Subscription pricing is perfectly valid for online services that are not open-source.
Free? Free is the worst. I don't get any trust that the service will stay around, it can completely change along the way to "paid", and I don't get to keep anything in that case.
if it's NOT good enough as-is then why bother using it in the first place?
Take a look at ProfitWell for instance, they do the same thing: Give away their core product then make money on upsells.
Also, building the business model as they go is pretty normal for a startup.
This just means that what used to be free will end up costing money when whatever new features they think they can charge for won't get enough users to cover their costs.
This is especially true if the free plan is more than enough for most users. Which, if you're positioning yourself as a Jira alternative -- most users won't need in-depth AI planning for sprints.
It's not a great business plan...
No, they explain how they currently hope to make money. That's a long way from being the same thing.
Consider this: for an existing service with lots of data to back up its pricing, a price list can be treated as an effective guarantee of what the service will continue to cost into the long-term. The company knows that the pricing model is profitable - and therefore, raising prices won't be worth the massive customer outcry.
For a new company, a price list is speculative. There is no way to do accurate long-term extrapolation of profitability. If the prices turn out to be too low to sustain the business, they will have to be raised - and while there will be an outcry, the business will simply have no alternative.
And since it's really hard to migrate all your data/workflows/integrations/etc. away from the service you first decide on, you're incentivised to never join a new service - because the price instability might come back to bite you, let alone if the company itself doesn't collapse later.
Nope
> How is that different from setting a price list on their website? They hope people will pay them doesn't mean they will
Agree; I would make the same comment if someone claimed a price list meant a business was stable and worth relying on.
Without that you have to rely on them surviving if you want to use their platform long term.
That being said, our entire ethos is to have a functional free forever plan, where users can manage their tasks and run their sprints, without worrying about hitting a 10 user limit, limited-time trials or task limits. We're avid supporters of open source, and we believe closed source software should have wider availability. So much of B2B software is behind paywalls, demos and short trials, hence our approach.
It feels like there's a lot of stagnation here, also. If I was building a product management tool, I would certainly not make it anything like Jira. Jira's a bit of a "dirty word," anyway -- it's a monolithic system that seems to suck more productivity than it generates. Where's the innovation? The last truly revolutionary productivity tool was Slack, and maybe Dropbox before that.
I don't mean to throw any shade at the Tara people -- it seems like a ton of work went into the product. But I guess I just don't really get the state of the market (even though I work as an engineer and am often-times force-fed these kinds of tools).
It's an interesting conundrum and one that we think B2B software rarely gets right. Why can't B2B software inspire delight in the user and just work?
We've decided to have a laser focus on teams that ship early and often, and help with their workflows, by innovating through design. That being said, we still have a long way to go.
Tools like Jira reflect these complexity on us during customization and are rated by their capability to handle them.
The Gitlab and Github issue trackers do that and aren't that bad for managing large scale projects actually. Their weakness is that they are inherently tied to a single source repository and most teams and organizations would have many of those. Fragmenting information across multiple issue trackers is not ideal. IMHO Microsoft is on to something by grabbing Github and deeply integrating it into their stack. CI/CD is where the action is and a lot of that is cloud centric and a great opportunity for upselling things like Azure. I've been keeping an eye on the github issue tracker and they've added some nice features there related to project management. There's also codespaces, project discussions (in beta currently) and a few other features that basically indicates to me that they want to be a one stop shop for anything a development team needs. An org level issue tracker that aggregates information from all source repos and their issue trackers would be a great move for them.
Jira has plugins for github integration that I've never seen working properly; most of them you need to pay for to even find out if they work or how. But the core issue is that this is clearly an afterthought for Atlassian and their tools are generally UX challenged resource hogs that are poorly integrated with each other even. They don't do github because they are still flogging the dead horse that is bitbucket; which is thankfully a lot less commonly used than gitlab and github. Basically they have a lot of me too products; I like exactly none of them. Trello used to be kind of nice and they sort of bolted it onto Jira in a weird way.
We are currently on Asana and kind of liking it but the lack of github integration is not great. What's also not great is the lack of markdown support and things like code samples. But it gets the job done and the non techies in our company like it too; which is important for us.
For a lot of projects I do, the release process these days is centered around github releases and github actions. E.g. we have internal libraries that we tag that get subsequently built and pushed to package repositories. A new release typically addresses pull requests and closes issues. It signifies the movement of those issues from doing to done (i.e. deployed/live/etc.) and reviewed (pr approved). The act of creating a branch can signal the act of starting a task. I consider work in progress pull requests a good practice for these as you get to have early feedback and discussion around it.
Any tool that forces me to do task transitions manually is fundamentally wasting my time. Releases have release documentation associated with them. Compiling a list of "what did we actually change" manually is likewise busy work you should not have to waste brain cycles on. So deep integration with tools is the next logical step for a good issue tracker. Most existing ones don't do a great job of it. That's the market opportunity.
Atlassian is ready to be disrupted. They got too big and bloated and they are not on top of their game for a long time. There are a lot of dinosaurs using them and a lot of misguided PMs insisting that the Atlassian way is THE way. IMHO they probably should but can't afford to gobble up Gitlab and that's actually a good thing. A reverse takeover would be a great lateral move for Gitlab actually. Also Google or Amazon could do worse then attempting to buy either (or both) and mirror Microsoft's strategy of owning everything relevant to running a software project in house.
Would you mind elaborating this shift?
Anyways, Good luck with the launch!Will give this a go.
1) inherent subconscious bias on the part of the recruiting team 2) pedigree bias - employers only wanting to view candidates that were from certain ivy league institutions
We tried long and hard, for a good 18 months, and it became an arduous battle fraught with the possibility of having to make unethical decisions in the structure of our algorithms. Our whole thesis was to create a system that recommended candidates based on their github repos. Pretty sure someone will solve this problem, but in our experience, it felt like a losing battle since recruiters wanted access to certain types of candidates and were continuing to reject candidates that were surfaced, with non-traditional backgrounds.
This was 2015, I think someone will solve this problem with time. The experience did teach us a thing or two about git commits, PRs and the overall experience of productivity through git based systems.
Oh I was disappointed. Logging in on a mobile device was already cumbersome. Finally checked on the desktop and tested a bit. But the UX is so messy! It's really not clean nor simple to use.
Would never want to use that with SCRUM. Just having to think about on boarding customer to this tool gives me headaches.
Recently, we have switched to https://linear.app (note: I have no affiliation with them). It's just super amazing to use, lots of shortcut, clear, dead simple, well documented. Perfect balance for us.
Hope this comments helps both the team behind Tara and some other looking at alternatives.
Looks a bit dated and somehow hard to customize.. but at least you keep your data (ai models, you say?) you get to keep it when "free" is no longer a valid business model.
This was just published - a quick guide on setting up the Gitlab webhook: https://help.tara.ai/hc/en-us/articles/360051704951-Gitlab-I...
They seem to use their "milestones" as sprints in the examples, but its a little clunky.
"THIS IS A WEBSITE PRIVACY DRAFTED UNDER U.S. LAW. THIS POLICY IS NOT INTENDED TO SATISFY ANY 'FAIR PROCESSING NOTICE' OBLIGATIONS THAT YOU MAY HAVE UNDER GDPR OR OTHER APPLICABLE NON-US LAW."
As a European, it's very unfortunate that I'm not legally able to try your product.
I can't see court in the EU ruling in favour of the employee on this specific topic.
More likely the GDPR notice is to remind people about customer data. Which is fine, that's the right thing for Tara to do. However any company using a Tara-like solution for putting customer data on would be in the wrong. That sort of practice would have failed PCI DSS even before GDPR was a thing.
That's nothing to do with my employer having my name.
- You can ring the employer up and receptionists will readily hand this information over
- Many companies host AD off site
- Business cards
It trivial to find the names of people who work in a team because it's leaked everywhere and for everything.
I guess maybe, just maybe, if you happened to work in a sensitive industry (eg secret services) then there might be a claim here, but no such organisation would host that kind of development content off site in the first place. So it's a moot argument.
The reason Tara publish their GDPR statement is very clearly regarding customer data. Arguing about names and email addresses of customer facing project managers massively misses the point of what GDPR exists for.
I'm talking about their customers.
The GDPR message is there to stop Tara customers from putting other customers data in there. Like if I'm a customer of Tara and I provide services to you then you are my customer (not Tara's nor an employee of Tara). The GDPR is to tell me not to put your details in there. It's not there to warn me about my own email address being pseudo-public.
The reason this needs to be explicit is because sometimes some organisations will put their own customer data into their support system. While this is generally bad practice it can be excused depending on the type of support system it is and how it's hosted. But the type of system Tara is aimed for, it's not intended to be a customer issue tracker ("customer" here meaning "customers of the people who use Tara" -- not Tara's employees nor Tara's direct customers) and Tara are making that point explicit with their GDPR statement.
Sure, in your own comment thread that might make sense :-) I don't see why you think customer data is less worthy of GDPR than customers of customer data.
It's both great because it prevents loopholes, and shitty because you have to consider GDPR for fields that definitely should never have any PII in them.
I know GDPR doesn't, my point is if, as a business, GDPR is a requirement from your ticket tracking then you might need to rethink the data you, as a business, are putting on there. Something like this is not intended for tracking customer data. It's intended for assigning work and tracking throughput.
If you need to log customer data then you need a different type of issue tracking and something that project managers et al don't all have visibility of.
How is that their fault? They did not have the resources to follow your nation's regulations, so they chose not to support you. Perfectly reasonable business decision. Vote for better laws or move if you want to be able to take advantage of startups that cannot get past your regulation barriers.
(YouTrack is the Jira alternative, but it's not free.)
Personal opinion, so many PM tools tend to be bloated and each view ends up causing more mental overload for the team, EM and PM.
We've tried to focus on speed with performance and keeping things simple.
If you want "simple" there are already a thousand and one options available, but alternatives to Jira are extremely rare. This is how Atlassian captured the market.
So in my opinion you should really change your marketing, as it is it really gives off a false advertising vibe.
OTOH, Tara's simplicity is godsent, especially as a small team. The comparison makes sense to me.
I like the style :)
mg@WorkOS.com
We (I'm from the dev team) don't aims to re-do a "simple" alternative to jira because there are tons of them and they fall short when things to track get more complex. You can do simple (as github) you can do hellish (as jira) but unlike jira, you don't mandate one model over another (no hundreds of un-necessary fields because someone asked them once).
It's GPL, there is an entreprise plan, it's available on prem and cloud.
Because that’s what makes everything else in Jira a sorry kludge
To its essence, an ID allows interested parties to track something over time.
If you add additional meanings to an ID - e.g. the parent project as Jira does, or the kind as in ServiceNow - these can become outdated over time, and deceiving.
I'd say it's ok to change the "external name" as this other metadata changes over time (project name, bug, task, story, whatever...) but make the obsolete synonyms redirect to the currently active name.
URL unfurling was shipped today with the slack app, and quick actions are coming in a few weeks.
Obviously, you wouldn't want to have things migrating between projects - but if that is even concievable for an issue to do, then the division in 2 projects was probably not correct and it should perhaps have been a single project. That is: the PROJA-0001 is as immutable and unchanging as 1000001 is.
A thing changing "kind" (e.g. a bug to a feature) doesn't seem far fetched, and I'd be reluctant (Meaning I think it would be a flawed design) to use that as the public identifier prefix for a feature.
I get why they want to compare Tara to Jira, but when you look at what companies actually do with Jira, then you'll hit a wall rather quickly with pretty much everything else.
Like them or not, Atlassians product integrate rather well, and you can "easily" customize them to integrate into pretty much everything else. We have Jira integrated into pretty much everything from monitoring to invoicing.
You can also customize the snot of internal workflows in Jira, per project basis. Even to the point where nothing makes sense any more.
Finding a replacement is hard, but relevant given the latest pricing changes from Atlassian. That and their idiotic prioritisation of their cloud offering. Oh yeah, and no Atlassian product has a functional search feature.
A platform for productivity, should have zero to minimal setup, built-in views and it should work hard to get out of your way.
If it helps, creating a sprint is 1-click on Tara. And I'm hoping it stays that way!
Wait let me reread.
A free jira alternative.
"Use sophisticated drag and drop to make sure your project is properly micro managed with Workboards.
Grab ahold of tasks, literally. Place them in confusing, new orders. Make a column just for interns! Ignore the backlog forever."
They might be british
- Runs on Linux, Mac OS X
- Also "runs" on Windows.- on-prem - kanban with no sprints?