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!
ApolloRising 1267 days ago [-]
Just signed up and so far everything worked well. Couple tweaks, you may want to use more than 1 letter for the workspace name icon in the left menu when a user has a few workspaces since naming is unpredictable.
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.
iba99 1267 days ago [-]
Hey! So we had the option for a min char count, but users wanted to have one letter workspaces (for fun I guess?). We need to revamp our navigation anyway since it's hard to know where to click to change workspaces.
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!
ApolloRising 1267 days ago [-]
Will do and good luck!
drcongo 1267 days ago [-]
Can I be the first to ask _how_ it's free?
freddier 1267 days ago [-]
The website mentions in the pricing popup:
>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.
drcongo 1267 days ago [-]
Thanks
oxfordmale 1267 days ago [-]
@iba99 If only company founders could be forced to pay for "free forever plan" once they are no longer free. In reality "Free for ever" seems to mean "free untill I sell the company"
loufe 1267 days ago [-]
Any plans to accommodate privately-hosted git servers?
iba99 1267 days ago [-]
Not yet but it would form part of a future on-prem version of Tara, where privately-hosted instances of Github/Gitlab are accommodated.
dnsmichi 1267 days ago [-]
Thanks for sharing. I'm curious about the GitLab integration, is there a page on your website describing it in more detail?
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.
danudey 1267 days ago [-]
Is there a reason for announcing it now, when it's incomplete and less useful, rather than once it's done (or more feature complete, at least)?
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.
iba99 1266 days ago [-]
Solid point, but I would counter that a feature or a product is never truly complete. The goal should be to get to a stage where users can derive value from the feature (or product), and ship.
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.
crdrost 1267 days ago [-]
To set up my question, maybe I should share a sort of hazy crackpot vision or dream. So when I look at Git, I see a variety of postmodernism that's like “look, we’re not being pretentiously intellectual or even pessimistic—we’re being realistic, software just is a postmodern world, Alice and Bob both have software that they call ‘Linux’ on their laptops, and they just aren’t the same source code, but they are both Linux, and trying to assess which one is the “true” Linux really does devolve into asking questions about power and basically in this case the power is vested ultimately in one king, Linus Torvalds, who says which one is more modern, and that’s fine as long as you understand that it’s arbitrary and anyone can fork the project at any time and create a rival power-structure and so forth.” Like, these ideas that I made fun of when I was a kid turn out to be amazingly practical things as finally revealed by git enlightenment.
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?
cat199 1266 days ago [-]
holding 'truth' as a single fixed thing is not 'modernist' any more than being relativist is true because it is what people do in some social setting.
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')
crdrost 1266 days ago [-]
I’m not sure that we should read postmodernists as being willy-nilly relativists. Like certainly the sort of “practical postmodernism” that I see in Git is not willing to say “Linux is BSD” the way a relativist might. Linux is a unix kernel and more broadly an operating system and a community led by Linus Torvalds for several years and a dozen other things besides, postmodernists would claim—and that there is no Archimedean “sturdy enough place to stand” to tell you which of these definitions is the “best”—but it is not a bouncy castle or a monad burrito tutorial or whatever nonsense I just “cook up”. Like the philiospical postmodernists’ criticism of the modernist “reason is going to solve the problem of finally accessing truth and we are gonna have a big truth party” is that reason essentially makes a 2D projection of a 3D truth, and so you have to approach the same truth from multiple perspectives with reason to get a full appreciation for it. Reason does not eliminate the problem of perspectives—sort of a Platonic fallacy, that reason will give you one single “world of the forms”—and that it shouldn’t even try because perspectives are great, let’s have some more perspectives.
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.
wheresvic4 1267 days ago [-]
I really enjoyed your setup to the question and it did really make me think about issue management in deeper detail.
I think that one of the points that you raise is quite valid - that issue tracking should really be integrated into version control.
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.
divbzero 1267 days ago [-]
As a current and former user of BitBucket, Confluence, Jira, and HipChat, the look and feel of Tara is miles away from any Atlassian product. After reading the parent comment, it still took me a few times switching back and forth to notice that both logos happen to be triangular and blueish, and even then the logos are easy to distinguish — obtuse vs. acute apex, curved vs. sharp legs, different shades and gradients of blue.
dotancohen 1266 days ago [-]
You're right.
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.
dotancohen 1266 days ago [-]
On second thought, all publicity is good publicity. Maybe drawing the attention of Atlassian would be good from a marketing perspective. They would effectively let Atlassian initiate a comparison between the two products.
xaedes 1267 days ago [-]
Why is the user in the "terms and conditions" called a "tester"?
> 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.
3r8riacz 1266 days ago [-]
Maybe you always use the beta version for free, and only the paid plan will use the fixed production build?
viach 1267 days ago [-]
> Our free forever plan has unlimited tasks, sprints and workspaces, with no user limits.
If so, what obstacles prevent from open sourcing it? At least the the part of functionality which is declared to be free forever?
anaganisk 1267 days ago [-]
Post open-sourcing: HN article with headline, how Amazon ripped us over night.
On a serious note, why should a startup make its code open source, unless they want to. Source open is also not acceptable for majority of HN. n8n tried to use a license that restricts commercial usage, and HN was all pitchforks.
georgyo 1267 days ago [-]
It is free now, they never say it will be free forever.
serial_dev 1267 days ago [-]
How do you interpret this in the "Pricing" modal:
> Our free forever plan has unlimited tasks, sprints and workspaces, with no user limits.
viach 1267 days ago [-]
I interpret it as "we will somehow monetize your data and train our AI model on your activities"
syed99 1267 days ago [-]
Hey! Co-founder/CTO of Tara here.
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.
viach 1267 days ago [-]
Interesting, just had this idea - would it be possible to feed the model with wrong data and make it giving bad suggestions to competitors who opted in?
syed99 1267 days ago [-]
Ha! Yes to some extent it would but that would really mean either a) we decided to run recommendations using a sparse model or b) we never validated the data or kept a watch on models when they were trained/retrained. This type of manipulation is typically likely when you're much larger and have alot of bots involved on the platform.
0df8dkdf 1267 days ago [-]
The fact that it is .ai means that they are doing data collection. And you are the product.
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.
hobby-coder-guy 1267 days ago [-]
So a competitor isn’t made.
ComputerGuru 1267 days ago [-]
How is “an AI for teams” a replacement for Jira, which doesn’t market itself as an AI at all? I’m looking at your features and I don’t see anywhere that AI plays a role in the core offering? Can you provide more info on how this is your distinguishing feature?
gorpomon 1267 days ago [-]
It's hard to find but if you click pricing, it pops up a modal with a FAQ:
> 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."
eecc 1267 days ago [-]
Perhaps they’re using AI to predict capacity “based on past sprint performance”
/s
hobby-coder-guy 1267 days ago [-]
Is that a bad idea?
lekevicius 1267 days ago [-]
"Free" is the worst pricing of all.
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.
chimen 1267 days ago [-]
Free like in Netlify where you end'up paying hundreds of dollars/month for a static side hosted on a cdn. Free means: settle in, bring everything you have over here, come on, we will discuss pricing later on when you're stuck in my bubble.
darkhorse13 1266 days ago [-]
Don't mind me asking, but what exactly are you doing with Netlify? Your pricing seems a bit excessive to say the least.
chimen 1266 days ago [-]
Not doing it any more since I migrated to Firebase. avg of 700 visitors/day to a Gatsby blog coupled with forms that send about 10 email/day that was it yes.
kilroy123 1267 days ago [-]
Hundreds? What is costing you so much?
pj_mukh 1267 days ago [-]
FWIW, they explain exactly how they'll make money in the website (under Pricing) and in this thread.
robertlagrant 1267 days ago [-]
> FWIW, they explain exactly how they'll make money in the website (under Pricing) and in this thread.
No, they explain how they currently hope to make money. That's a long way from being the same thing.
newswasboring 1267 days ago [-]
This is such a nothing statement. How is that different from setting a price list on their website? They hope people will pay them doesn't mean they will
ivanbakel 1266 days ago [-]
Because the speculative version is much less trustworthy - and because this kind of service is prone to data lock-in, trust in pricing/profit-models is particularly important.
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.
robertlagrant 1265 days ago [-]
> This is such a nothing statement
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.
masukomi 1267 days ago [-]
we hope to get you dependent upon our product, and in the meantime come up with something we hope you'll be willing to pay for is not the most confidence inducing of business plans. Also, if the current plans are "free forever" have no caps on users or much of anything else and are good enough to use until they actually finish off the things worth paying for then how many folks are actually going to be inclined to pay for them?
if it's NOT good enough as-is then why bother using it in the first place?
ZephyrBlu 1267 days ago [-]
The business model isn't anything special... It's just freemium.
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.
mbreese 1267 days ago [-]
> building the business model as they go
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...
ReD_CoDE 1267 days ago [-]
Where's their source code? I don't see anything open-source
adamnew123456 1266 days ago [-]
AFAICT they're not, and I think that's the point of GP's criticism. If it were FOSS you would have the option of figuring out the hosting and migration story yourself if the company goes under.
Without that you have to rely on them surviving if you want to use their platform long term.
1267 days ago [-]
iba99 1266 days ago [-]
We're a few months away from introducing Tara premium, which includes access controls for teams and user level permissions (ie contributor, etc), and is based on simple subscription based pricing. It's pretty much what our users have asked for, and we're continuing to listen to their feedback.
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.
dvt 1267 days ago [-]
This is a bit of a meta-discussion (apologies to the people at Tara, they did a fantastic job!), but is the market really large enough for the insane amount of productivity tools that have been released over the past few years? From Airtable, to Monday, to Hugo, to Tara, to Asana, etc., etc.
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).
rubyron 1267 days ago [-]
Software is “eating the world,” as they say, and selling blue jeans and pick axes to gold miners is a perennially solid way to make money.
iba99 1267 days ago [-]
At it's core, we find it to be an Apple OS vs Windows OS problem. You can either build highly complex project management systems, with 50 different types of subsets, customizations and setup instructions (ie Windows?) or try to design software that just works through simplicity in design and set defaults based on your workflow (ie Apple!).
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.
oaiey 1266 days ago [-]
The problem here is that processes in enterprises are never default. Depending on the company the requirement to these processes are always different.
Tools like Jira reflect these complexity on us during customization and are rated by their capability to handle them.
jillesvangurp 1267 days ago [-]
I think Tara is on the right track by doing a deep integration with Github and Gitlab. IMHO project management tools need to track progress automatically where possible and grab relevant information related to pull request status, CI/CD feedback etc.
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.
zed88 1267 days ago [-]
It's an interesting pivot for you guys from building some sort of recruitment AI (I remember seeing it somewhere) to this.
Would you mind elaborating this shift?
Anyways, Good luck with the launch!Will give this a go.
iba99 1267 days ago [-]
In our experience building any form of meritocracy in recruiting, was excruciatingly difficult due to
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.
geniium 1264 days ago [-]
I was interested to test this to see if it could add some values to our team. And am always curious to see what other people come up with.
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.
LysPJ 1267 days ago [-]
Speaking of Jira alternatives, I recently discovered Kitemaker [1], which is really nice. The UI is clean and it's fast too (has keyboard shortcuts for everything, etc).
Hi. Co-founder of Kitemaker here. Thanks for the kind words! Do let us know if you have any feedback or improvements you'd like to see.
syats 1267 days ago [-]
Just wanted to mention Redmine, which is actually GPL and can be installed on premises.
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.
I don't see anything on the website about Gitlab integration
smartbit 1267 days ago [-]
Gitlab CE free edition has many plan features https://about.gitlab.com/features/#plan including Milestones, Issue Board, etc. What features is gitlab ce lacking, that makes you want to use a 3rd party planning product?
jahlove 1267 days ago [-]
sprints, epics, kanban boards.
They seem to use their "milestones" as sprints in the examples, but its a little clunky.
iba99 1267 days ago [-]
We haven't had time to update the homepage or the overall website, just been focusing on shipping early and often.
"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.
anonytrary 1266 days ago [-]
> As a European, it's very unfortunate that I'm not legally able to try your product.
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.
ComputerGuru 1267 days ago [-]
Is there anything that legally (on the user’s side) stops a European user from using an American service that doesn’t collect/operate on address information but bills their service as “for USA only”?
whimsicalism 1267 days ago [-]
It might be problematic if they ever want to charge customers of their AI service in Europe.
hnlmorg 1267 days ago [-]
Are you routinely putting GDPR sensitive information into your ticket tracking system? I'd suggestion most people shouldn't irrespective of GDPR. And if you don't then those terms aren't an issue.
robertlagrant 1267 days ago [-]
People's names could be in their logins, which means you have a portion of their employment record.
hnlmorg 1265 days ago [-]
That's a bit of a stretch. Any large organisation would already have a central database of employee names and job titles that are accessible to everyone within the organisation. That data is available to anyone who looks up an email addresses, let alone any web based services such as Sharepoint. Many businesses even advertise their team publicly as part of their marketing,
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.
robertlagrant 1265 days ago [-]
No. I'm saying that Tara would have access to both my employer name and my name if they had my work email address as a login.
That's nothing to do with my employer having my name.
hnlmorg 1264 days ago [-]
Yes, I got that point and you're missing mine: employer databases are seldom treated as confidential.
- 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.
robertlagrant 1261 days ago [-]
All of your examples are for someone's own employer. I'm not talking about people who work for Tara.
I'm talking about their customers.
hnlmorg 1260 days ago [-]
I'm not talking about people working for Tara -- I was only ever talking from the perspective of Tara's 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.
robertlagrant 1252 days ago [-]
> I'm not talking about people working for Tara -- I was only ever talking from the perspective of Tara's customers!!!!
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.
curryst 1266 days ago [-]
I don't think GDPR differentiates between sensitive info you asked for, and sensitive info that somebody chooses to put in a field not meant for it.
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.
hnlmorg 1265 days ago [-]
> I don't think GDPR differentiates between sensitive info you asked for, and sensitive info that somebody chooses to put in a field not meant for it.
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.
madrox 1267 days ago [-]
A little off topic, but has anyone else noticed that when you look at any product that shows off their client list, Cisco is on it most of the time?
otabdeveloper4 1267 days ago [-]
This thing is in absolutely no way a Jira alternative.
(YouTrack is the Jira alternative, but it's not free.)
iba99 1267 days ago [-]
For us, the key was to build a simple Jira alternative. A good PM tool should do the basics, and get out of the way.
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.
otabdeveloper4 1267 days ago [-]
"Simple" isn't a Jira alternative; not being "simple" is Jira's entire raison d'etre.
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.
mrweasel 1267 days ago [-]
Jira is a project management tool? I think that one of the only things we don't use it for.
taejavu 1267 days ago [-]
It's a great operating system, lacking only a decent project management tool.
krick 1267 days ago [-]
That's surprising to hear. What do you use for this purpose then?
mrweasel 1263 days ago [-]
CRM, service desk, CMDB, trouble ticket, tickets in general, we just don’t use it to manage project. We have tried things like the Kanban board, but it’s not all that good. Our PM find it easier to keep the tasks in Jira, but do the planning i MS Project
otabdeveloper4 1267 days ago [-]
Jira is a communication and documentation platform. You can bolt on some agile project management stuff (Kanban boards and whatnot), but that stuff always seems like a fifth wheel for Jira.
krick 1264 days ago [-]
That doesn't answer the question. And, just for the record, "Kanban boards and whatnot" is exactly how we use Jira.
pj_mukh 1267 days ago [-]
We went from Jira to Tara (with Notion in the middle), and the problem is everyone thinks they need Jira, and a huge swath of people really don't. Jira is a complex product and those complexities are probably needed by some people.
OTOH, Tara's simplicity is godsent, especially as a small team. The comparison makes sense to me.
iba99 1267 days ago [-]
Hey PJ! We've loved having Placenote on board. Hoping the new slack integration works well for you guys- if not just ping! FYI - notifications on sprint reports are shipping in 2 weeks.
gjvc 1267 days ago [-]
Make no mistake, if it's free, you're the product.
chrismorgan 1267 days ago [-]
When I click on “Release log” near the bottom of the page (which isn’t a link, BTW), it loads https://tara.ai/undefined which loads the front page again and then changes its URL back to https://tara.ai/.
nishparadox 1267 days ago [-]
Hey, our startup recently moved to tara because we couldn't afford jira. Thanks for this tool. We've been using it for a month or two now and the task management seems to be doing fine. Not that we are that much managed, but still tara seems to be a good (and of course, free) alternative to get the things done.
BtM909 1267 days ago [-]
@iba99, what tool did you use to create (or how did you create) the promo video on the homepage?
I like the style :)
iba99 1267 days ago [-]
Framer!
poleapple 1267 days ago [-]
Does Tara support a public facing board to capture bugs feature requests from our users? We would like to be able to link public facing issues to internal issues.
iba99 1267 days ago [-]
Not yet but it's on the roadmap! Several pen source repositories are requesting this feature as well, to monitor development with their contributors and we need to ship this. We've discovered there are very few options for open source communities to monitor and track/report on progress - and the cost for hundreds of contributors can become prohibitive with other PM tools.
nahtnam 1267 days ago [-]
And upvoting would be good as well! Not sure how you'd authenticate or maybe allow anon votes?
iba99 1267 days ago [-]
I think we would just integrate with an existing tool for this vs building it ourselves.
poleapple 1267 days ago [-]
Thanks for the reply.
autotune 1267 days ago [-]
Do you offer SSO auth like Okta integration?
iba99 1267 days ago [-]
On the roadmap but looks like we should checkout WorkOS :)
grinich 1267 days ago [-]
Happy to help! :)
mg@WorkOS.com
eeZah7Ux 1267 days ago [-]
"Free" in the title should not mean free-as-in-been on a website called "hacker" news......
mister_hn 1267 days ago [-]
But where can I download it without doing a login and doing self-hosting? Where's the "free"?
steve_taylor 1267 days ago [-]
Given the timing, I was expecting to see an on-prem alternative to Jira, so this is disappointing.
vaceletm 1267 days ago [-]
For an on prem alternative to Jira, you can have a look at Tuleap.
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.
eecc 1267 days ago [-]
Does it have something like JIRA-1330?
Because that’s what makes everything else in Jira a sorry kludge
iba99 1267 days ago [-]
What's your take on changing the status quo around unique task/issue ID's?
eecc 1267 days ago [-]
Can't say anything more than: it depends.
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.
alkonaut 1266 days ago [-]
The prefix is just a project name though? It's no different from a convention saying that IDs 1000XXX are for project A and IDs for 2000XXX are for project B, it's just easier to read and distinguish like PROJA-0001 and PROJB-0001.
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.
derektwong 1267 days ago [-]
Curious, do you mean: if a task was part of project ABC, with an ID of ABC-123, then if someone moved it into project DEF, its ID is now changed to DEF-621, those two should be linked, right?
iba99 1267 days ago [-]
One way we've tried to fix this is with our slack integration. Using the task URL, or ID, the integration quickly unfurls context in the task (showing story info) and allows quick actions. Same process with requirements/epics.
URL unfurling was shipped today with the slack app, and quick actions are coming in a few weeks.
valcker 1267 days ago [-]
Why change something that works? It is much easier/faster to use short IDs than long user story titles.
3np 1267 days ago [-]
Is self-hosted on the roadmap?
mrweasel 1267 days ago [-]
One would hope, that's one of Jiras best features, even if Atlassian clearly doesn't agree.
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.
SOLAR_FIELDS 1267 days ago [-]
I think that "nonfunctional" is a bit of an undersell. I've used Confluence for years and while I don't think the search is great by any means, it's certainly usable once you figure out its quirks. I think we are all spoiled by how great Google is about edge cases and deriving meaning from your queries and we are too quick to judge other search offerings.
iba99 1267 days ago [-]
Yep.
3np 1266 days ago [-]
sweet!
mkarliner 1267 days ago [-]
I really, really don't want another Jira.
iba99 1267 days ago [-]
Nobody does. It's ridiculous that it takes 21 clicks to create a sprint. We've literally timed ourselves in every Jira instance (cloud and next-gen), and every point of configuration, setup or action just takes hours.
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!
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?
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.
I think that one of the points that you raise is quite valid - that issue tracking should really be integrated into version control.
https://tara.ai
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.
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.
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...
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.
[1] https://kitemaker.co/
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.
https://www.openproject.org/jira-alternative/
They seem to use their "milestones" as sprints in the examples, but its a little clunky.
This was just published - a quick guide on setting up the Gitlab webhook: https://help.tara.ai/hc/en-us/articles/360051704951-Gitlab-I...
"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.
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.
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.
(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.
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.
URL unfurling was shipped today with the slack app, and quick actions are coming in a few weeks.
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
- on-prem - kanban with no sprints?