Since then, we've continued to chip away at the problem of building responsive project management software, that syncs to Git source control and works with no setup. A re-designed Atlassian stack if you will, with automation based on Git events. So we can finally stop updating tickets as often as we do; the work is already in git, and it should be automatically reflected in our issue tracking or project management software.
With support from HN, we’re getting closer to this mission. You've spent time with us in calls, video sessions and over boba, to talk through how you ship mission-critical product updates, and how Jira continues to frustrate your teams, because it just wasn't designed for shipping.
Today, we're releasing a host of new features. Tara AI 2.0 delivers a new design optimized for creation, zero loads, automated workflows, and our new restful API.
Also, you can now create tasks, requirements, with automated roll-over for sprints, in 1/4th of the time it takes in typical PM software. We've created a hierarchy system with a universal work drawer, so work can be viewed and organized across the workspace.
As always, our free plan is still free for unlimited users, with upgrades available to premium or co-pilot plans.
I'd love to hear your feedback & thoughts. Thanks!
The only reason we're going to move away from JIRA is that Atlassian dropped server installs and is moving everyone to their cloud or datacenter products.
Have a great conversion from JIRA and a reasonably-priced self-hosted option, we'll be looking at you in six months.
Its definitely something we've been exploring when putting our product roadmap together. I'm curious though, if we had a private cloud instance vs self hosted? I'd love to understand why self hosted would be the option you'd go for.
Our security policy doesn't let us put confidential information into other people's hands unless they are willing to commit to the full value of damages from a breach on their side.
It's a great question to differentiate sales critters: the new ones are sure that they can work something out; the middle ones are dubious; the experienced people chuckle and disengage politely.
I think for most/many European companies, especially those that are potentially handling PII, there are regulatory concerns with using US based hosting/companies.
My employer for instance has put a ban on deploying anything new on AWS/Azure/Google Cloud until legal issues have been settled after Privacy Shield was invalidated.
Everything new right now needs to be on EU/EFTA data centers run by EU/EFTA companies. This essentially means self hosting since most clouds are owned by US companies.
A lot of orgs have various regulatory constraints. For much of public sector, you're either going to need to be able to have it hosted on AWS GovCloud or allow the organization to self host it on their own servers.
Sure, at absolutely stupid price increases especially for smaller orgs. It starts at $42,000 a year... Also known as 840$ per user if you have 50 users.
With GitHub we sync all the issues in real time. So all changes you make in Tara reflect on GitHub issues too. We make it easier for larger teams who run sprints and require a more accessible interface work better together i.e designers, PMs and EMs.
For the Gitlab for the time being we only allow connection of issue tickets to MRs and some organized views of commits and MRs in our progress mode.
Any plans of supporting kanban boards in future? We find that kanban works very nicely to manage certain types of projects, and we're currently using Jira's kanban features for many projects. I'd love to see alternatives.
Sync'ing with self-hosted Git servers would be good to have. Many of our projects are hosted on Git servers in a "secure network" behind a corporate VPN that, for legal and commercial reasons, cannot be hosted externally. Any thoughts on this?
We do plan on supporting kanban views over the next few months. It’s a WIP along with list views.
The question about self hosted git servers, we do support them but not officially through the GitHub app which is on the App Store. We do have a fully compatible backend that can integrate with any self hosted git using webhooks, we haven’t exposed those to users as of yet.
Thanks for the response, though my question was more about whether you've thought through how your webhooks based approach can work through VPNs.
For example, one of the organisations I work with uses a CheckPoint capsule VPN with some non-standard configuration that's controlled by their IT department that manages and supports client workstations.
To even access the Git server requires the user to be connected through VPN. I suppose you'll need Tara to follow the same route to the Git server that's sitting behind this VPN, right? This would be quite a different story than having Tara connect to a public facing self-hosted Git server, e.g., on our own data center or on AWS.
I suspect this will he a hard (impossible?) problem to solve unless Tara itself goes self-hosted and is on the same VPC as the Git server behind our VPN.
We use JIRA and GitLab at work. In the GitLab CI/CD configuration we define a few hooks that update JIRA task status on various events (MR is created, MR is merged, etc). It's a bit of manual work but it's working flawlessly for years. How is it different from this offer?
It works the same way for the automations but it’s a one click set up for GitHub. It’s makes it easier for Team leads or people who may not have the resources to bind together workflows and it ensures consistency in experience. Secondly we also infer statuses on PRs and through CI/CD that let you know where features are in the pipeline (coming very soon). Our aim is to make powerful git event drive features more accessible with the least amount of configuration.
Tell me about the sync... how complete is it?
And the pricing... how do you accommodate OSS projects?
Our scenario is that our work comes in from multiple places, i.e; OSS community (one repo), SaaS offering (another repo) and Enterprise offering (another repo). What we're trying to achieve is a single pane of glass for a team to see all of their work, but the work to remain in the respective repos. So whatever tool we use must treat Github Issues as the system of record, and any tool must reflect what it does in Github. And further, it would be great to make that single pane of glass dynamic... i.e; I'm a Prometheus engineer and I want to create a team/project that aggregates all work on Alertmanager across all of the big projects that use it (even the ones that exist in other orgs).
ACK that our use-case may be at the extremes of what others do, so it's cool if this is not yet possible.
Additionally with the OSS repos per-user licensing of potentially all contributors is a tough ask, we would have no control over our pricing and most contributors would be idle... they're not employees, but we'd want to ensure the community could use/see the same tools that we would use, how could we enable community involvement in the tools without exposing ourselves to a loss of control over the operating costs of it?
Hi there, we currently don’t have a bitbucket integration but it’s on our roadmap towards the end of the year. We will however be updating our migrate tools early Q4 with Jira/Confluence mapping.
Readit News
Since then, we've continued to chip away at the problem of building responsive project management software, that syncs to Git source control and works with no setup. A re-designed Atlassian stack if you will, with automation based on Git events. So we can finally stop updating tickets as often as we do; the work is already in git, and it should be automatically reflected in our issue tracking or project management software.
With support from HN, we’re getting closer to this mission. You've spent time with us in calls, video sessions and over boba, to talk through how you ship mission-critical product updates, and how Jira continues to frustrate your teams, because it just wasn't designed for shipping.
Today, we're releasing a host of new features. Tara AI 2.0 delivers a new design optimized for creation, zero loads, automated workflows, and our new restful API.
Also, you can now create tasks, requirements, with automated roll-over for sprints, in 1/4th of the time it takes in typical PM software. We've created a hierarchy system with a universal work drawer, so work can be viewed and organized across the workspace.
As always, our free plan is still free for unlimited users, with upgrades available to premium or co-pilot plans.
I'd love to hear your feedback & thoughts. Thanks!
The only reason we're going to move away from JIRA is that Atlassian dropped server installs and is moving everyone to their cloud or datacenter products.
Have a great conversion from JIRA and a reasonably-priced self-hosted option, we'll be looking at you in six months.
It's a great question to differentiate sales critters: the new ones are sure that they can work something out; the middle ones are dubious; the experienced people chuckle and disengage politely.
My employer for instance has put a ban on deploying anything new on AWS/Azure/Google Cloud until legal issues have been settled after Privacy Shield was invalidated.
Everything new right now needs to be on EU/EFTA data centers run by EU/EFTA companies. This essentially means self hosting since most clouds are owned by US companies.
Both Github and Gitlab have built-in project management features! Why should I use a different tool if I'm using Github/Gitlab?
For the Gitlab for the time being we only allow connection of issue tickets to MRs and some organized views of commits and MRs in our progress mode.
Sync'ing with self-hosted Git servers would be good to have. Many of our projects are hosted on Git servers in a "secure network" behind a corporate VPN that, for legal and commercial reasons, cannot be hosted externally. Any thoughts on this?
The question about self hosted git servers, we do support them but not officially through the GitHub app which is on the App Store. We do have a fully compatible backend that can integrate with any self hosted git using webhooks, we haven’t exposed those to users as of yet.
For example, one of the organisations I work with uses a CheckPoint capsule VPN with some non-standard configuration that's controlled by their IT department that manages and supports client workstations.
To even access the Git server requires the user to be connected through VPN. I suppose you'll need Tara to follow the same route to the Git server that's sitting behind this VPN, right? This would be quite a different story than having Tara connect to a public facing self-hosted Git server, e.g., on our own data center or on AWS.
I suspect this will he a hard (impossible?) problem to solve unless Tara itself goes self-hosted and is on the same VPC as the Git server behind our VPN.
Our scenario is that our work comes in from multiple places, i.e; OSS community (one repo), SaaS offering (another repo) and Enterprise offering (another repo). What we're trying to achieve is a single pane of glass for a team to see all of their work, but the work to remain in the respective repos. So whatever tool we use must treat Github Issues as the system of record, and any tool must reflect what it does in Github. And further, it would be great to make that single pane of glass dynamic... i.e; I'm a Prometheus engineer and I want to create a team/project that aggregates all work on Alertmanager across all of the big projects that use it (even the ones that exist in other orgs).
ACK that our use-case may be at the extremes of what others do, so it's cool if this is not yet possible.
Additionally with the OSS repos per-user licensing of potentially all contributors is a tough ask, we would have no control over our pricing and most contributors would be idle... they're not employees, but we'd want to ensure the community could use/see the same tools that we would use, how could we enable community involvement in the tools without exposing ourselves to a loss of control over the operating costs of it?
The Dev files - the source code is out there
Dancing with the git stars.
(I could go on).