[HN Gopher] Show HN: Tegon: Open-source alternative to Jira, Linear
___________________________________________________________________
Show HN: Tegon: Open-source alternative to Jira, Linear
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 :)
Author : harshithmul
Score : 118 points
Date : 2024-07-09 06:01 UTC (16 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| Daviey wrote:
| 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
| harshithmul wrote:
| 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
| magicalhippo wrote:
| 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.
| harshithmul wrote:
| 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
| magicalhippo wrote:
| Sounds great, will check it out!
| wanderingmind wrote:
| If you are planning to monitise it through SaaS, might be
| worthwhile to change the license to AGPL from MIT.
| harshithmul wrote:
| 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.
| zamalek wrote:
| 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.
| harshithmul wrote:
| Understood, Thank you. Really appreciate all that
| information.
| KolmogorovComp wrote:
| Using BSL would make their code source-available but it
| wouldn't be open-source anymore, unlike AGPL.
| evantbyrne wrote:
| 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.
| KolmogorovComp wrote:
| 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.
| evantbyrne wrote:
| 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.
| satvikpendem wrote:
| 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.
| evantbyrne wrote:
| 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.
| satvikpendem wrote:
| 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.
| evantbyrne wrote:
| 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.
| kshri24 wrote:
| 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.
| malcolmgreaves wrote:
| 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."
| Daviey wrote:
| 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.
| mort96 wrote:
| 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.
| satvikpendem wrote:
| 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.
| malcolmgreaves wrote:
| 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.
| inhumantsar wrote:
| 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.
| xyzzy_plugh 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.
| satvikpendem wrote:
| 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.
| xyzzy_plugh wrote:
| 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.
| satvikpendem wrote:
| 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.
| satvikpendem wrote:
| 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.
| circularfoyers wrote:
| Do you support local LLMs? I could only see an ENV for
| OPENAI_API_KEY.
| Manik_agg wrote:
| Hey another co-founder of Tegon here, currently we only support
| Open AI models but plan to add local models support with Olamma
| soon.
| hrpnk wrote:
| There is also COHERE_API_KEY for the vector storage & search:
| https://github.com/tegonhq/tegon/blob/158b54af8d6f7cf4195c61...
| deepak_sozial wrote:
| how is it different from the mighty plane.so?
| lawgimenez wrote:
| Why does plane.so look exacly like linear.app?
| tommoor wrote:
| I think you can guess
| lawgimenez wrote:
| Yeah, I just searched some past discussions regarding
| plane. Not good
| harshithmul wrote:
| 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.
| throwaway_fjmr wrote:
| 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.
| harshithmul wrote:
| 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.
| faust201 wrote:
| 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
| harshithmul wrote:
| 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.
| magicalhippo wrote:
| 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.
| harshithmul wrote:
| 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
| magicalhippo wrote:
| Sounds great, will keep an eye out.
| naveensky wrote:
| I am curious, why would you like to do this?
| zamalek wrote:
| This is a bit of an extreme ask, that's basically an entire
| product in its own right.
| itomato wrote:
| All the data is there, you just need to connect to it with a
| new class of BI tool. It's coming.
| zamalek wrote:
| 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.
| itomato wrote:
| 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.
| itomato wrote:
| 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.
| threecheese wrote:
| 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.
| itomato wrote:
| What evidence do you have that suggests auto-generated titles are
| better?
| harshithmul wrote:
| 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
| itomato wrote:
| Lack of "crispness" in user titles is a tooling problem?
|
| Isn't this "wrinkly" technical detail lost?
| harshithmul wrote:
| 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.
| CapeTheory wrote:
| 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.
| harshithmul wrote:
| 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.
| denysvitali wrote:
| > True performance is our top priority
|
| The server is written in Node.JS
| harshithmul wrote:
| 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.
| giovannibonetti wrote:
| 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.
| haswell wrote:
| Node is capable of significantly better performance than
| the average Jira instance.
|
| The bar is low.
| harshithmul wrote:
| 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.
| inhumantsar wrote:
| 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?
| harshithmul wrote:
| 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.
| peter_l_downs wrote:
| 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.
| peter_l_downs wrote:
| 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.
| harshithmul wrote:
| 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.
| harshithmul wrote:
| We are still working/improving on the documentation. We use
| mintlify for documentation
| https://docs.tegon.ai/introduction.
|
| Noted. We will work on it.
| peter_l_downs wrote:
| I appreciate the quick responses. Sincerely, best of luck.
| harshithmul wrote:
| 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.
| hrpnk wrote:
| > 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.
| mort96 wrote:
| > 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.
| codegeek wrote:
| 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.
| mort96 wrote:
| That may be, but you need to not have "AI" or "AI-first" in
| your description in order to be an interesting
| product/project.
| maximilianburke wrote:
| I'm getting a "no healthy upstream" error from the demo link.
| hrpnk wrote:
| 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...
| shafyy wrote:
| 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.
___________________________________________________________________
(page generated 2024-07-09 23:00 UTC)