Show HN: Tegon: Open-source alternative to Jira, Linear | Hacker News Reader

Show HN: Tegon: Open-source alternative to Jira, Linear

github.com

163 pointsharshithmul128 comments

Hi HN, we're Harshith, Manoj and Manik and we're building Tegon (https://github.com/tegonhq/tegon), open-source issue tracking software that uses AI to smartly automate manual workflows or provide more context to engineers for a given task. There's a demo video here: https://www.loom.com/share/b664b01e9b064a02be5791c12b77a107, and you can try out the product at https://demo.tegon.ai using these credentials:

  Email: elon@xyz.com
  Password: XfFNw6GwVJVQv6PA

As engineers, our experience with traditional tools like Jira hasn't been great. It is slow, bloated and often acts as a burden to engineers. These tools didn't help engineers in getting the work done faster, they only helped the management in tracking the work which enabled a lot of processes and micro-management which used to kill our productivity.

With the rise of LLMs, we thought about how project management and issue tracking would look 5-10 years from now. The current tools didn't match our vision, which excited us and started the journey of Tegon. We aim to build a tool where manual workflows are either automated or handled by AI. This tool will provide better context about a task to an engineer by smartly gathering data from all sources, helping teams with better prioritization.

Tegon loads all the data from local (indexed db) thus making it super fast to load and navigate. We make all of this happen by real-time sync in the background. Tegon also uses AI to simplify the issue-creation process by automatically creating titles, suggesting labels and assignees and identifying duplicates. Tegon also simplifies the issue creation process from Slack, just apply an emoji to a Slack message and a tegon issue will be created making it easier for other teams to raise bugs or feature requests to engineering teams.

We deeply value the feedback from this community and have spent the last month revamping Tegon's design based on the feedback from our last launch. We just got started and there's a lot more to come. We're eager to get more feedback and keep building. Let us know what you think in the comments :)

Open articleView on HN

Having worked quite deeply with Jira and a host of other enterprise products that target this set of use cases, and having a pretty good understanding of what decision makers are looking for when evaluating these products for fit (I have been that person), what does "AI First" mean?

I realize AI is the hype right now and it seems like most products have to pay the AI Tax (i.e. "Yes we're doing AI stuff so you should <buy/sell/fund/etc> our stuff"). But "AI" is a nebulous category, and when a product bills itself as "<Noun>-first", it sets up an expectation that <Noun> is fundamental to the product, i.e. if you stripped all other aspects of the product away, what's left at the end is <Noun>. But I have no idea what that means in the context of the current "AI" hype.

Based on your demos, you've built a fairly standard looking ticket tracking tool that has some AI features. And those are features that every incumbent in this space started adding to their products years ago or are actively doing it now.

I mention this not because I'm trying to say your product doesn't have value, but because the way you're positioning this doesn't make a lot of sense to me. As a prospective buyer, if I'm already using an existing tool, the moment I start digging deeper to know what "AI First" means, I'll find that what this really means is "Jira but with some AI features on top", which isn't very compelling when my <Vendor> account team has been telling me all about their new AI features that I can start using on all of my existing data as soon as I upgrade, no 6-18 month migration required.

If I'm a frustrated customer of those products, AI is not the reason I'll be looking to switch, and I'd be far more likely to be interested in performance, extensibility, openness, integration capabilities, etc.

Maybe that's not the type of customer you intend to target, but if you hope to reach them, I leave this as food for thought. Best of luck to you.

> as soon as I upgrade, no 6-18 month migration required

Maybe not a 6-18 month migration, but you will have a similar wait for Atlassian to deliver something approaching functional.

Of course this doesn’t matter to the leaders that can now claim their ticket tracking is AI enhanced, but the net value of the feature at that time is negative or zero.

Otherwise I agree though. Frustrated Atlassian customers do not move because they really wanted AI.

Really appreciate the thoughts. The places where we believe AI matters a lot is

1. Ensuring ticket has enough information 2. Offloading some amount task before someone picks it.

These are the 2 key areas we are focusing and we will launch some features around these in the coming weeks. Would love to hear if there are some other places you feel we can focus on?

What about, instead of using AI to summarize the issue text for the developer, using AI on the _submission_ end to notice if the bug report doesn't contain enough details and ask the submitter clarifying questions until the submission is a really good bug report?

> If I'm a frustrated customer of those products, AI is not the reason I'll be looking to switch, and I'd be far more likely to be interested in performance, extensibility, openness, integration capabilities, etc.

Sounds like this is what they should be asking you more about.

Would you mind rattling off some a wish list?

Perf I can imagine but some of the others not so much in detail.

> what does "AI First" mean?

Copious amounts of gratuitous hallucinations contaminating the data you are looking to work with.

Someone had to call it out!!! thank you for that.

Oh, the AI hype! It's basically just common sense wrapped in a shiny new package.

Let's call quick filters 'AI' and be amazed, shall we?

When the dataset is limited, what magical tricks can AI pull? Joining threads or conversations is just a fancy wildcard search. Where's the real optimization?

all that i wanted to say, only better.

i am a zero-to-one guy and i get that this kind of positioning is often forward-looking, but i think that's what early-stage founders get wrong, especially if they aren't core whatever-noun they are anchoring to.

if you consider all other incumbents in this space, they are all AI-driven. your differentiator could be AI only if you are core AI and have drawn up models for project or work management use cases. otherwise, just stick to whatever your differentiators are in the near-term and change positioning later when you are core AI.

Taskade did this well. Notion is doing it well. they are all pivoting around AI without trading off whatever's their core.

IMO the absolute most important thing with a tool like this is performance. I have to sign in to a handful of cloud desktops each week and interact with customer Jira/Confluence/AzureDevOps/etc pages, and the big thing which kills my engagement is the app not being snappy enough. Doesn't matter how many of the features our Agile SAFe scrum wizard wants me to use, I'm not going to bother if there is too much friction. These apps inevitably require a lot of clicks, so latency becomes very noticeable.

True performance is our priority. From the very beginning, we focused on ensuring that our app ran smoothly and quickly. To achieve this, we load all the data locally, allowing you to experience everything at lightning speed. Our background server keeps your data synchronized seamlessly between the server and the client, so you get the best of both worlds: speed and reliability.

> True performance is our top priority

The server is written in Node.JS

My bad. We focused on the performance on the front end currently, as said before we loaded all the data locally and kept the data synced in the background to make the interactions fast. We chose nodejs as that was easy for us to get started with. But definitely, if things get hampered we will start looking into it.

Good call. Front-end performance is often the bottleneck. Preloading most of the required data in advance is really helpful. Trello does just that and it is one of the snappiest web apps.

Node is capable of significantly better performance than the average Jira instance.

The bar is low.

That is entirely orthagonal to the issue. NodeJS can be Fast.

We are also working on a more chat-based approach to interact with the tool. To let you directly handle things from the messaging tools like slack.

I completely agree. I've often found myself copy pasting links to slack threads or screenshotting messages to append to tickets. being about to flag a thread and have a service create a ticket, summarize the discussion, highlight the requirements, and (importantly) include the things we decided against doing, would make life so much easier.

the flip side of course is that the easier it is to create a ticket, the easier it is to create duplicate or contradictory tickets. does your system offer the ability to check for existing tickets that are a close match for whatever is being created?

Hey, that's where we bring in triage grouping and duplicate identification. We show you what are the similar issues and we are also working on smart merging so to merge the information from both the issues.

First, congratulations on launching. I think people are so used to seeing beautiful products these days that it can be hard to remember how hard it is to make anything. Nice work! With that out of the way, here is some critical feedback:

- What is the pitch that you made to YC that convinced them to back you? The market size just doesn't seem that large and I don't understand what will differentiate you from Linear (whose design language you seem to have ripped off, somewhat poorly.) This post and the current featureset is vague and does not seem like a significant improvement. What is the core problem you're solving and why is that valuable? Your launch post above describes a lot of "how" but not a lot of "why".

- Why are you bothering to pretend to be "open source"? You're backed by YC and you'll make money selling access to the product on your "Tegon Cloud". If you're really going to be open-source, you need to make some significant improvements before anyone would consider contributing. Some documentation on how to self-host would be a good start. Look at all the environment variables in this dockerfile — which ones are necessary to run this service myself? https://github.com/tegonhq/tegon/blob/main/docker-compose.ya...

- If you're going to be "open source", the quality of your codebase and engineering skills is going to be a deciding factor in whether or not you get outside contributors. Consider writing actual descriptions in your pull requests, describing what you've done and why. Here's a PR picked at random — this is bad engineering work and does not encourage others to contribute. https://github.com/tegonhq/tegon/pull/114

My advice is that you drop the facade of being "open source", hire a designer, and do some actual user research to figure out where people are actually struggling with their ticketing systems. The features you're building (automatic title suggestion, thread summarization, and "find similar tickets") do not solve the problems that I have had with ticketing systems. They're small, potentially nice-to-have features that absolutely do not help me understand the core question for all engineering teams: who is doing what, how will they do it, why, and when will it be done.

By the way, you've left the notiz.dev LICENSE file in your server code, probably you want to remove that.

https://github.com/tegonhq/tegon/blob/158b54af8d6f7cf4195c61...

Separately, there seems to be a ton of unused or broken or dead code sprinkled throughout — for instance, in the auth code, I can't tell if you're doing basic email/password auth or using Supertokens and a third-party login via Google. You have code for both and some routes seem dead or missing.

https://github.com/tegonhq/tegon/blob/158b54af8d6f7cf4195c61...

Also, I mentioned the lack of documentation for how to run Tegon locally because your docs are entirely insufficient. The main docs page is just a README template. https://github.com/tegonhq/tegon/tree/main/docs

The quickstart guide has a broken link to instructions on how to self-host https://github.com/tegonhq/tegon/blob/main/docs/quickstart.m...

The oss/local-setup guide is entirely empty https://github.com/tegonhq/tegon/blob/main/docs/oss/local-se...

The oss/deploy-tegon guide does not explain anything and the script it references seems out of date https://github.com/tegonhq/tegon/blob/main/docs/oss/deploy-t...

I'm done looking at this project. I strongly recommend hiring the best engineer you can find as quickly as you can.

thanks for the catch. We will remove those.

Yes, we use Supertokens and we support email/password and google auth. Google auth is something we added recently as that was requested.

We are still working/improving on the documentation. We use mintlify for documentation https://docs.tegon.ai/introduction.

Noted. We will work on it.

I appreciate the quick responses. Sincerely, best of luck.

Note that “open-source” does not imply anything about quality, or your entitlement to that. As was already noted they’re selling access to a cloud product that you are entirely welcome to use if you do not want to think about how the code works.

> or your entitlement to that

Calling something open source to get traction doesn't entitle a project to much anymore, too. Gone was the time that open source was synonymous of creating public software while building a community. What we see here on Show HNs is pure marketing strategy.

Thanks a ton for the feedback.

1. We started our documentation at https://docs.tegon.ai, though it is not ready yet points taken, and we will work towards making more documentation.

2. We are planning internally to bring more systems to how we manage PRs and to have the right information on them.

3. We love opensource and we have built all our previous products opensource. Keeping our love aside we believe the building of a marketplace for agents/integrations is where the community can help us a ton. We are currently working on making that more modular so that people can start contributing.

What we have done till now started with the basic Project management and there is a lot more to be built and to solve.

> Keeping our love aside we believe the building of a marketplace for agents/integrations is where the community can help us a ton.

You wanna customers that act like salesman. Who doesn't? What the community can help you with doesn't seem to align with what you can help the community with.

Hey, we are still early and are figuring out things. Thanks for being candid, was there something you are interested in seeing in the product? (use case, feature etc)

> Look at all the environment variables in this dockerfile — which ones are necessary to run this service myself?

It would also help to sort and de-duplicate the variables in the file. COHERE_API_KEY is listed twice. Adding a comment per block of API keys on what they're for would also be nice.

> Linear (whose design language you seem to have ripped off, somewhat poorly.)

I thought I recognised the name. When it was first posted to HN[1] it was repeatedly criticised -- and seemingly flagged to death -- for being a carbon copy of Linear's design. After that the screenshots were removed from the repo with a "We are redesigning our product" notice[2] until this design was released ~3 weeks ago[3].

Good on them for trying to redesign -- I think it's good that they gave it a shot -- but it does still look quite similar.

[1] https://news.ycombinator.com/item?id=40290735 (https://archive.is/Yd010)

[2] https://github.com/tegonhq/tegon/commit/4887ac7e678197f77243... (https://archive.is/MGHeF)

[3] https://github.com/tegonhq/tegon/commit/dafb4337f6a446dba328... (https://archive.is/ABXYk)

If you are planning to monitise it through SaaS, might be worthwhile to change the license to AGPL from MIT.

Thank you for your suggestion. You’re absolutely right; we are actively exploring licensing options, including AGPL, to ensure that our product remains protected.

We value input from the community and are open to suggestions and assistance in making this decision. Our goal is to prevent unauthorized copying and resale of our product under different names while fostering a collaborative and innovative environment.

While the community may be a good source for ideas, you should retain an attorney. The community is not your lawyer.

There's also the BSL. It specifically calls out competitive products. It automatically falls away for code older than a given time to another OSI license: https://en.wikipedia.org/wiki/Business_Source_License. Per the Wikipedia article this still has issues: contributors are handing over their work for to you for free for that duration, they can't use their own work for profit.

The AGPL does make your project extremely unattractive to competition, without affecting your contributors. The issue is that it is still possible to compete with you using it, so long as your competition releases all their code (i.e. infra, billing, etc.) under AGPL.

I would personally go for AGPL because it will keep the worst offenders (Amazon, Microsoft) away from your code.

Understood, Thank you. Really appreciate all that information.

Using BSL would make their code source-available but it wouldn’t be open-source anymore, unlike AGPL.

The Business Source License allows for redistribution and modification of code. Calling it not open-source because it restricts third-parties from slapping a logo on it and selling licenses seems like a stretch. imo licenses like the BSL are really the direction that open-source should be heading in, because they allow the original author to retain their rights while avoiding exploitation by rando corporations.

No, it’s not an open-source license because it’s not OSI compliant https://opensource.org/licenses.

Open-source has a specific meaning that too many people don’t know or forgot.

This feels like splitting hairs and unnecessary gatekeeping, and I'm not sure for what purpose or for who's intended benefit. The movement needs to evolve to better protect the rights of the people actually doing the work, because they are the ones who are benefiting the least by the narrow definition being pushed by the OSI. Maybe we need a new term if this is how "open-source" is seen in the broader community.

The term is "source available," but I guess with that, companies can't use "open source" as a marketing term then pull the rug after they got enough contributions, like so many that converted to BSL and others now. By creating rights for those companies such that they cannot be competed with, you actually remove the rights of users, which is the whole reason the open source and free software movements got started in the first place. They are and always have been about the rights of users, not of corporations.

What are you talking about? I don't know where you live or what project you are referring to, but it's not possible to retroactively remove someone's rights in the American legal system by publishing a new license. If you committed code under a MIT license without signing anything else, you don't lose anything when later versions are published under BSL, AGPL, or whatever. The fact that the MIT license arguably allows willy nilly relicensing by anyone should be seen as a flaw with that license, not BSL. Also the context of this conversation is what license is appropriate for a new project. It makes less sense to apply a BSL to a MIT licensed project that has been around for a while than it does to start off with a BSL.

I'm not even sure how what you're saying relates to what I said; of course no license can be retroactively changed and I never said anything to the contrary. By rug pull, I mean companies like Sentry or MongoDB starting off as open source then changing their license such that they are no longer open source, making it a much more difficult legal minefield for whomever uses their product, even if they aren't competing with them, as they are now source available companies. As a copyright holder, any license can be changed for the future, whether it be MIT, AGPL, or BSL. With regards to a new project, sure, they can license it however they want but if it's not open source, they should expect to get way fewer contributions than if it were.

Well that's certainly disappointing but not really a rug pull so much as just what eventually happens with every project, which is that at some point the original authors stop contributing to the original vision. Both of the mentioned projects also don't use BSL, which I feel it is worth reiterating is still a very permissive license. If you aren't planning on selling licenses to the project you are contributing to, then a BSL isn't going to meaningfully restrict you. Sure, fewer contributions is a theoretical concern, but fully permissive licenses also suffer from contributions not looping back into the original project. Or if you use something in the GPL family there are other implications. I've been reading a lot about licensing lately and there don't seem to be any obvious choices for authors who care about how their work is used. I'm gravitating towards BSL though because it is relatively simple and feels like it retains the most important aspects of open source, which are redistribution and modification.

> This feels like splitting hairs and unnecessary gatekeeping, and I'm not sure for what purpose or for who's intended benefit.

The line must be drawn. Open-source absolutely needs to have a firm definition, otherwise it will be whittled away to nothing. Microsoft already tried that with "shared source".

If you think the difference between BSL and AGPL is just splitting hairs, then why not just use the AGPL?

There is less of a difference between BSL and MIT than between any GPL license, as I'm sure you are aware. If I'm giving away software including source in the open, for free, while allowing redistribution and modification, then I'm not sure how to convey that without offending patrons of the OSI and FSF. Not feeling like walking around on eggshells to give things away that's for certain.

> There is less of a difference between BSL and MIT than between any GPL license, as I'm sure you are aware.

Nonsense. There is an enormous difference between the MIT license, which grants you permission to use and sublicense something without any restrictions, and the BSL, which does not.

> If I'm giving away software including source in the open, for free, while allowing redistribution and modification, then I'm not sure how to convey that without offending patrons of the OSI and FSF.

If you put limitations on how that software is used, then no, you're not giving it away. That part is something the OSI and FSF have been very clear about for decades - see e.g. the FSF's "four freedoms", which are about as clear and simple as you can get.

Even silly "camel's nose" limitations count, and have to count, otherwise there is no place to draw the line; see the OSI and FSF's comments on the HESSLA or the (pre-2021) JSLint license. Again this is something they've been clear about for decades.

> Not feeling like walking around on eggshells to give things away that's for certain.

If you want to give things away for free then do so. If you want to pull a Columbia Record Club "it's free, no wait you have to pay us" scam then of course people aren't going to support that.

Brother, let's agree to disagree. I'm not involved in any of these licensing dramas as I don't have any feelings of entitlement to free labor. People can give away as little or as much as they please.

There's no "agree to disagree" when you're doing something that (whether you intend it that way or not) will end up scamming people. Don't tell people your code is open source when it's not open source. Don't tell people your code is free when it's not free. It's not entitlement to expect people to keep their word, even if you didn't pay them.

Accusing people of "scamming" you by giving you something for nothing, and putting their extremely permissive terms in clear writing, is acting entitled. You're not the lifeguard on this beach, so draw your lines in the sand somewhere else. Good day to you sir.

> "scamming" you by giving you something for nothing

Again, Columbia Record Club

> putting their extremely permissive terms in clear writing

If the written terms are clear already, why do you want to call it free/open source? (Which it isn't)

Do you really not understand that the colloquial use of these terms differ, and that most people don't even know about the FSF and OSI? On the other hand, the license has always been the law and everyone knows that. If you're just going off someone mentioning they "open-sourced" their work, not checking the license, and importing that into corporate projects, then you could end up with anything and would frankly be lucky to later find a FSL or BSL rather than something in the GPL family. Being scammed and just being dumb are two entirely different things, and you have yet to point out any real scams.

> If you're just going off someone mentioning they "open-sourced" their work, not checking the license, and importing that into corporate projects, then you could end up with anything and would frankly be lucky to later find a FSL or BSL rather than something in the GPL family.

You would expect to be able to run the program freely, including as part of your production services, without incurring any obligations. And under any open-source license (including GPL-family) you can, because that's part of what open-source means. Getting presented with a bill because the program turned out to be BSL and the way you were using it means you need a commercial license is absolutely a scam.

Do read these two great books by Heather Meeker:

1. Open (Source) for Business: A Practical Guide to Open Source Software Licensing

2. From Project to Profit: How to Build a Business Around Your Open Source Project

This video presentation by her on this topic is really valuable too: https://www.youtube.com/watch?v=Ck1gJIZ3Lr4

You will then have a really good idea of where to start. As the parent poster said, it is wise to switch to AGPL if you want to build a COSS business.

You can also expressly state that you have a commercial license too. Your entire license can be something like “ If you’re using it for commercial purposes, you must see a commercial license with XYZ. Otherwise, for all noncommercial uses, you may use the software according to the terms of the AGPL license.”

Please define "commercial use", because it means different things to different people.

Also, lots of organisations have a blanket ban on AGPL, so offering it under an alternative commercial license is a great approach to enable them, but explicitly blocking it for "commercial use" makes it no longer free software, which would be a shame.

Commercial use is making money with the software.

You could certainly iterate on the terms to strike the balance you want. You could make the source available to commercial clients as well. Each client can have a licensed tailored to their exact needs at a price that works for the people that make this software.

It's much more nuanced than that... Sure, we can agree that if I host and charge users to use the service it is commercial usage... but:

  - If my limited company use it to manage internal development, but we aren't yet profitable (making money), is it commercial use?
  - If a company uses it to manage internal development, but it isn't the product itself, is it commercial use?
  - If I as an individual use it to manage a non-commercial side development project, and when it is then finished, I decide it is worth value and I sell it, does it become commercial usage, and my previous usage turns out to be non-compliant?
  - Is a charity using it to manage an internal development project "making money"?
  - If I as an individual provide a professional service to deploy this to "non-commercial" users, is this compliant by the license?

You really can drive a truck through the definition of "commercial use", it is nearly as bad as the original JSON license, which stated "The Software shall be used for Good, not Evil." - which is helluva subjective.

Wait which non-commercial uses would there be for this product? I guess you'd only use it as an issue tracker for open source projects with no funding?

Regardless, by doing that the software would no longer be open source, and it seems like being open source is a significant part of the marketing strategy currently.

Doesn't the AGPL allow all uses including commercial? How would this work?

You can make a license with any terms you want. You can embed the exact text of the AGPL into another license. And that license can have an if-else branch where the predicate is “are you making money with this or not?”

Yes of course but you can't call it the AGPL.

Note that anything other than MIT will immediately remove one of your major advantages over the competition. No enterprise wants viral licenses in their environment, it’s simply not worth the anxiety when there’s so many options.

If you want to compete on being open source your license has to be free.

AGPL doesn't prevent anyone from taking your code wholesale and hosting the entire thing. They didn't make any changes so they don't have to contribute anything back per AGPL. OP can make any part that interacts with it, such as billing and infrastructure code, closed source as they are the copyright holder and thus do not have to abide by AGPL or any license themselves. If they make every contributor sign a CLA, then even better.

If you build something interacts over a network with an AGPL’d program, then you are hitting the distributing over a network clause in the license.

But that only stipulates that the third party has to make the code available if they've modified it.

This is fine if you expect people to want to modify the backend, but it won't stop people who only care about cloning the service.

Which is sort of the point, good software made available to as many people as possible as cheaply as possible, but it's not really protection against others who would monetize the software you wrote.

I am not an IP attorney but this is undecided territory: as I understand it your integrations may be considered modifications, and thus may be subject to the terms of the license, depending on the interpretation.

If Amazon can successfully do it such that other companies whose products they were hosting had to relicense to source available from AGPL, then, based on the strength of their lawyers, it is likely that those integrations are not actually needed to be released. And even if they were, it doesn't really matter, people don't use AWS for their source code.

I am not sure how to interpret what you have written. Are you suggesting Amazon operated and sold AGPL-licenses software, and thus made a licensed program available over the network, but did not comply with the terms of the license? I am not aware of any evidence of such.

Amazon repackaged MongoDB, an originally AGPL licensed work, and did indeed comply with AGPL, but that means nothing because they did not modify the source code at all, they merely packaged it up into a hosted service. Because they followed the terms of the license but were accused of "leeching off" of MongoDB, even though they clearly licensed it to be used as such, MongoDB then changed their license to a source available one. My point is that if Amazon's lawyers, which are likely better and stronger than most anyone here on HN's, approved such actions with regards to AGPL works, then it's very likely that they were within their rights to do so via the terms of AGPL without open sourcing their integrations too.

What evidence is there that they repackaged MongoDB? How did they "comply" with the AGPL? It seems like they reimplemented it which would be no AGPL licensed works are involved.

This sounds like a myth. There is no way AWS legal would allow providing access to an AGPL licensed work over the network.

So what? Amazon is perfectly content distributing the source code, because they don't actually modify it, only host it. That was the main issue that caused many companies to relicense to source available.

Would it be possible to run AI/ML on an existing jira/github large project (k9mail/KDE(gitlab) and show/prove this can be useful/better etc? Thanks

We haven't yet modularized the AI features of our product. Currently, it's not possible to use the AI features on top of JIRA/GitLab. Our AI capabilities have achieved better accuracy and output because we have more control over the infrastructure and the product's foundations.

Additionally, incorporating agents and managing their workflows require a distinct set of metadata and separate workflows, which we are still in the process of exploring.

Since one can self-host Tegon, do you have some importers working? That way I could import some Jira issues and see it in action on our own data.

If you have an API to manage issues, that could work as well. Would need that anyway for custom build integration etc.

We are in the process of building those scripts. As we are working with companies for migration we started to improve these scripts to cover more edge cases. These should be out sometime soon.

Otherwise, we have a public API to do CRUD operations for all important entities (issues, labels etc). We are working to get an openAPI spec once that is out we should have all the APIs added to our https://docs.tegon.ai

Sounds great, will keep an eye out.

Can you give me an idea of what you are using AI for currently?

Edit: Never mind, found the list you posted elsewhere.

Current AI functionalities: 1. AI-generated Titles 2. Smart Delegation 3. Duplicate Detection 4. AI Summarization 5. AI filtering 6. Automated Triaging

We are almost done working in 2 other areas 1. AI assistant while create a new issue ensuring the issue has enough information 2. Chat assistant to interact with the tool

Haha, same one. Thanks!

I am curious, why would you like to do this?

This is a bit of an extreme ask, that's basically an entire product in its own right.

All the data is there, you just need to connect to it with a new class of BI tool. It's coming.

That's missing the point. The root comment is asking for a different product (one that integrates with Jira) than the one offered by the op (one that replaces Jira). The manner in which such a product would exist isn't the concern of my argument.

That's not how I read it, but I don't see any case where offloading the entirety of IP in Jira to a third party makes any sense.

Probably not, from my experience. Certainly not for large installations. There's just too much to glean from a 20 year old Jira (Components, Comments, Issue History, Transitions, Links..) You can build a graph database from all of this (plus the metadata and other contextual stuff, like related code) which is what Atlassian did with their "Teamwork Graph".

Someone else's mystery machine is fine for a start, but if you want to train and test (and validate) your assumptions or do your own experiments, these AI features don't offer much.

If you are suggesting OP do this to demonstrate that their assertion is correct - that AI generated issue titles are objectively better - this is a Good Idea.

I have to guess /hope that they did this already; who would make a time investment like this without first proving that the product has value? Anyway I certainly wouldn’t even pilot it without some proof.

That’s a fun idea. I’ll have to see if I can run it on our Jira and Confluence instances to get better (or even minimal) ticket descriptions from the requirements.

You absolutely can if you add the context from correlations to Product and CX, brand tone and other bits of RAG.

You can study it all by graphing text extracts with NetworkX before you pay for an off-the-shelf LLM to provide a false sense of confidence.

The exercise will help you build the prompt regardless of what tech you use.

I'm getting a "no healthy upstream" error from the demo link.

We started seeing people creating random issues we will get it back up after cleaning it a bit

I was interested in how the duplicate detection of issues is working. It uses Cohere API for embeddings (full issue text) [1] and vector-based similarity search [2].

[1] https://github.com/tegonhq/tegon/blob/158b54af8d6f7cf4195c61...

[2] https://github.com/tegonhq/tegon/blob/158b54af8d6f7cf4195c61...

We tried different approaches, we made a recent change where we started using cohere for re-ranking and embedding which did give really good results.

Happy to create an account for you to try it out. harshith [@] tegon.ai

What evidence do you have that suggests auto-generated titles are better?

We thought auto-generated titles could make life a bit easier. Creating the perfect title for every task can be tricky, especially when things get complicated. So, we added this feature to help with that. (This is also something I faced as a challenge while I was working in Airbyte the community does a great job at explaining the issues but we always have to edit the title to make it more crisp.)

Right now, we’re using the product ourselves and trying it out with a few customers. We’ve noticed that for simple placeholder tasks, a straightforward title works just fine. But for more detailed tasks with longer descriptions, the auto-generated titles seem to work better. We’re still experimenting and gathering feedback to make it even better.

Examples from our board:

Description: - utils.py 228 : Failed to call LLM with the following error: BedrockException Invalid Authentication - An error occurred (UnrecognizedClientException) when calling the InvokeModel operation: The security token included in the request is invalid.

Title: Feat: Investigate Salesforce cloud version error: Invalid Authentication

Description: Triage ux bug - once i decline or accept a triage request, it re-directs me to issues screen. Ideal behaviour to be at the triage list view where you either show removing it from triage or highlighting that an action have been taken on this request.

Title: Redirect user to Triage List after Accepting/Declining Request

Lack of "crispness" in user titles is a tooling problem?

Isn't this "wrinkly" technical detail lost?

We were experimenting if it could potentially help in taking that off the plate. Feedback taken we will work on improving that or taking a call based on how it performs.

I don't know how to write this comment so it doesn't come off as unconstructive. But here you go.

- "AI-first"? What does that even mean? Calling some API to auto-generate a title? Do you really think that a) this solves a big user problem and b) that Linear can't add that in two seconds if they wanted to?

- Open-source and VC-backed? Please stop bull shitting me, and yourself.

- What is your USP? That you're faster than Jira? Fine, but this is not 10 years ago and snappy tools like Linear exist (and I'm not even a fan of Linear).

- elon@xyz.com? Really?

Please use your time and talent for something else than this VC AI pipedream. Or don't, I'm just a rando on HN.

Thanks for the feedback. We started this 4 months back and these are a few features we build. In the journey and as customers started using we figured out more strong features.

1. Context enricher - To ensure the ticket has enough information 2. AI agents - To offload some part of the work.

We will be getting these out soon

> that Linear can't add that in two seconds if they wanted to?

FYI Linear has had this feature for a while. It works quite well.

> AI-first

I would've been interested in an actual replacement for Jira/Linear, but I'm uninterested in an unreliable tool where I have to deal with hallucinations. Stop trying to cram this crap into every single software project.

Unfortunately, you need "AI First" to have any chance of VC funding for the past 2 years or so. They are probably keeping this in mind.

That may be, but you need to not have "AI" or "AI-first" in your description in order to be an interesting product/project.

The most obvious thing that should be done instead is to make an API spec that AIs can consume for your service, a common spec that if you target, any AI assistant can talk to freely. I feel like we're just over complicating things and burning money. Let the AI people burn their time and energy on the AI, let normal people build useful intuitive tools.

Do you think this would be useful for personal users as a todo/task management app? I have no chance of convincing work away from Jira, but I'm always on the lookout for a better personal task manager.

Hey, we have something in personal task management in our roadmap. We are still exploring how to solve that problem. Happy to hear thoughts on how you do it right now. https://github.com/tegonhq/tegon/issues/131

I logged in around 2024-07-09 10:22 UTC, and I hope the stories in review don't get accepted. You might want to demo the product in a slightly less open way, though.

Currently, our cloud service isn't publicly accessible, so we've been exploring the best way to demonstrate our product's features and functionality. To address this, we've created some demo credentials and a product instance for demo purposes. Additionally, we've taken a snapshot of a cleaner version of the product, which we refresh weekly.

We will also explore more to see if there is a better way to do this.

Thanks for sharing, can you tell us more about the functionality that AI has in your product and what Cohere does for you, above the capability of OpenAI? Ta

Current AI functionalities: 1. AI-generated Titles 2. Smart Delegation 3. Duplicate Detection 4. AI Summarization 5. AI filtering 6. Automated Triaging

Cohere: To improve smart delegation, duplicate detection, and automated triaging, we integrate Cohere's advanced NLP capabilities, ensuring more accurate and efficient similar issue searches.

We are bringing in more agents to delegate some of the work to them. 1. Code agent: This will help you in solving the small code fixes and small features but assigning issues to the agent and giving it instructions on how to solve them. 2. PRD agent: To help in PRD writing for the PM

we'll add more agents for different use-cases going forward

We have several working at support who struggle with writing good issues due to dyslexia, lack of technical knowledge (domain experts) or similar.

Was curious if the AI could assist them in a useful way. Sometimes they might poorly explain the problem, which module it pertains to or similar or similar, making it very unclear what exactly the issue is.

I was thinking perhaps an AI component that could analyze what they said and "complain" if the AI detects key information is lacking, or perhaps just re-summarize what they wrote so it becomes more clear when they haven't supplied sufficient information.

That sounds exactly like something which we will be launching next week. We are working on an AI assist which will ask questions while creating issues in aspects like

1. If that can be broken into sub-issues

2. If it lacks information according to a template that's created in association with the label. For example: Label bug: You can explain in the template what is expected (Some deployment information, logs, screenshots etc.) and the AI assistant will help in ensuring those contents exist.

We are also exploring if there are more such cases where AI can help. Do let us know your feedback on this once we launch

Sounds great, will check it out!

Finally got around to checking this out and got: "no healthy upstream"

Do you support local LLMs? I could only see an ENV for OPENAI_API_KEY.

Hey another co-founder of Tegon here, currently we only support Open AI models but plan to add local models support with Olamma soon.

There is also COHERE_API_KEY for the vector storage & search: https://github.com/tegonhq/tegon/blob/158b54af8d6f7cf4195c61...

llama.cpp supports being an OpenAI API server, you would just need to change the URL in the Tegon source.

linear set the bar so high but different projects have different needs.. i wonder how tegon and linear compare side by side.

how is it different from the mighty plane.so?

Why does plane.so look exacly like linear.app?

I think you can guess

Yeah, I just searched some past discussions regarding plane. Not good

Plane.so is indeed a great tool, and they emphasize creating an unopinionated platform that can be utilized by anyone.

Our approach, however, is AI-first. We are focused on integrating multiple AI agents into our tool to assist stakeholders in various ways, including automating manual tasks, providing enhanced context, and even resolving issues end-to-end. Our goal is to leverage AI to significantly boost productivity and streamline workflows for our users.

Reply on news.ycombinator.com