🍩 Doughnut Reader 🍩

I watched the demo video and at first I was confused why they were showing Linear instead of their own product. They just completely ripped off Linear. Gross.

I appreciate that what Jira is trying to do is hard. That might mean that it's trying to do too much and the industry would be better picking a different set of tools that don't try to do as much.

However, the biggest problem is one of misaligned incentives. Jira is meant to make a director's job easier at the expense of everyone else. It's a bit like Coupa: Coupa nearly requires an administrator, and increases the cognitive load of everyone in the org, but it makes the job of the accountants so much easier that people live with it.

(That said, I will be interested in how AI and Atlassian end up interacting. We all know it's coming.)

I think a lot of the criticism of jira really boils down to bad practices and being a bit careless with it.

However, jira’s performance when it comes to load times, query times, opening and updating tickets, etc. truly does warrant criticism. It introduces a substantial amount of friction when trying to manage multiple tickets, or just get things done.

It's been over 10 years since I last used Jira, but I still miss a lot of it. Where I saw it become a problem was that over time it accumulated layers and layers of people messing with it, especially as the company went through a phase of hiring project managers with a need to mark their territory by changing all of the workflows. What started out as a relatively lightweight tool used by the engineers to organize their work became a convoluted mess.

To be fair, that's not unique to Jira, and I certainly can't say I haven't put my own fingers in that pie.

Want to middle click this one specific link to open it in a background tab? Instead of respecting default browser behavior the user is expecting, JIRA happily hijacks the mouse down event to open your background link in the foreground instead, which prevents you from opening multiple links in a convenient timely manor.

A deployment happened on December 29th. It's January 2th. Suddenly, you need to know if the deployment happened 1 week ago or 1 month ago. You remember the deployments page usually says useful information such as X days ago or X weeks ago. Based on the facts, a rational normal person is expecting something like 4 days ago. JIRA says "last year".

Didn't they have an outage where they lost a lot of data for many companies a while back, or at least took months to get back?

We agree to it that JIRA is an elephant. It's also not gonna be an easy journey for us and we are all in for the long journey.

100%, flashed back the Garry Tan tweet too. This project would be great as an open source tech demo, but was quite surprised to see the YC logo on here.

(as a founder) I expect YC to understand the importance of iterative design and not throw money out of the window for a snapshot.

Hey Karri, I’m truly sorry for how things have turned out. Our aim was to highlight the importance of design, regardless of the project’s size. We never intended to copy Linear, but rather to consider it as an inspiration for any upcoming tools in this field, emphasizing the need for good design.

Rest assured, we will focus our efforts on these aspects and make sure to rectify the situation.

Yeah this is really frustrating to see Karri. You guys have built an amazing tool at Linear. I truly believe it has inspired everyone in the tech world who wants to build better software.

For this team to fully clone it, open-source it and then claim they were inspired by Linear is incredibly dishonest.

I know you already know this, what you all have built at Linear is a gold standard and the replicas wont be able to keep up.

thanks a lot. We will add these to our idea board, definitely a lot more work to do and things to build

I think git-bug[1] is the most popular project of that sort.

[1]: https://github.com/MichaelMure/git-bug

Very curious, in our understanding we thought the companies don't really have the time to spend their engineering bandwidth on project management. How do you think providing such an architecture can help?

What a great idea. Would love to see a project having a repo with separate src, docs, tickets folder, with infra having the ui to manage the non code contents.

We also have tried initially to build an SSR and get data from the server but when in the process we figured every time making an API call was slowing things down and adding up a lot of latency even if start adding complicated algorithms to the API call caching.

We think indexeddb also evolved in the recent years, but we will definitely keep an eye and keep improving with the available technologies.

In order to ensure everything is fast and real-time, we built a sync engine that runs in the background. We also use queues to perform some actions asynchronously. These factors influenced our decision to proceed with a server and scale as necessary.

We were comfortable with this architecture, having used it in our previous apps. This setup also offered us the flexibility to work quickly, as I focused on the frontend while my co-founder handled all backend tasks.

Our documentation is a work in progress, with our roadmap soon to be posted there.

We refer to the stages as workflows (To Do, In Progress, In Review, Done, etc.). Currently, we are focusing on the engineering teams and have predefined workflows. However, we plan to launch team-based workflow customization soon.

Regarding initiatives, we are working on a module that will provide a combined view of teams (such as Product, Design, etc.). This initiative module, for example, “Integrations,” will cut across these teams for better tracking.

[flagged]

We are working on this exact thing, would love to give you a demo and early access. My email is in profile.

Yes, we pledge to remain open source.

1. Our design is inspired by the linear UI, which we believe is the best. We didn't want to reinvent this aspect.

2. As for our differentiation, we've been building the system for two months and believe none of the existing systems prioritize AI. We're focusing on deploying AI agents in specific use cases such as:

    1. Task prioritization
    2. Feedback management
    3. Bug resolution

Isn't a dockerfile exactly a list of requirements to run it?

Check out the compose for the required services https://github.com/tegonhq/tegon/blob/main/docker-compose.ya...

And the server dockerfile for build + run instructions (it's literally just yarn build && yarn start:prod) https://github.com/tegonhq/tegon/blob/main/server/Dockerfile...

What’s stopping you from following the steps in the Dockerfile if you wanted to run it directly?

We've already transitioned few private beta customers from JIRA using a backend script. Although we haven't addressed all edge cases yet, we anticipate that this script will evolve over time. Once we've covered a sufficient number of scenarios, we plan to integrate this option into the UI.

We also plan to build an integration with JIRA where you can still use JIRA and link the issues in Tegon as you slowly migrate to our product. Similar to Github issues which is already live.

We have companies moving to Linear daily, so it’s possible.

And these can be anything from a 10 person company to 2000+ person companies.

We have jira sync that helps with transition. https://linear.app/integrations/jira

My company did. We moved to ClickUp. It is much better

Thank you. We chose open source for several reasons:

1. We are building for Engineering Teams: Being in the public domain allows us to collaborate openly with engineering teams and build a better product.

2. Building Trust in AI Agents: Trust is crucial in AI development. By going open source, we demonstrate transparency and accountability, enhancing trust in our AI agents.

3. Enabling Marketplace Development: Our vision includes creating a marketplace for AI agents (Integrating with multiple tools). Open source facilitates community involvement, driving the growth of this marketplace.

4. Community: We've noticed a gap in a vocal community focused on team management and mutual support. Our aim is to create a space where individuals can come together to share knowledge and assist each other effectively.

We love opensource. We have always built in opensource.

Hey we are working on the documentation and it's almost done and should be there by EOD.

You can use this one until they have theirs up, it will be identical /s : https://linear.app/docs

I've built a PoC for semantic search and chat for Jira. Just a CLI that uses the Jira API to iterate through all tickets and uses https://github.com/philippgille/chromem-go for creating, storing and querying the embeddings. The chat doesn't work very well, but the semantic search is very useful.

I always wondered the same. Or create a plugin for Jira, that does exactly that.

Indeed, this is a very valid case. Thanks for bringing this up we shall add this to our roadmap.

It's the same issue every time someone tries to brand themselves as an alternative to Jira. They implement 10/20% of the features, typically part of the task/bug-tracker and maybe the KANBAN boards and completely ignores the rest.

The fact that products and startups feel the need to brand themselves as "Jira alternatives" says a lot about the absolute dominance of Jira in some markets. You're just not going to replace Jira with a minimalist bug tracker. If profit is your goal, you'd probably be better of reimplementing your AI feature as a Jira plugin.

I think it's not about the Jira itself, it's about who manages it and power asymmetry it creates. If a bug tracker is configured by managers it will be optimized for manager productivity at the cost of developer productivity. Same thing often happens with infra/devops.

Can I customize it to select the epic and label on the ticket creation modal? I always have to click the link on the toast message to do these steps on a new screen, it's infuriating.

Looks solid to me for what it is. Especially if compared to jira.com

I see a video on the home page btw

I'm personally disgusted by it and I'm not associated or even a customer/user of Linear. Also shocked by people not caring.

> It's depressing

This may sound not-so-empathetic, but it is:

Capitalism is depressing. If we lived in a society where everyone shared and benefited together, then you wouldn't have to deal with this frustration of needing to hold onto value to ensure your survival.

Indeed, our user interface (UI) shares similarities with Linear’s. We, too, are fans of Linear and appreciate its user experience (UX). After speaking with a lot of people, we concluded that it’s top-notch. Consequently, we wanted to give that experience rather than attempting to reinvent the wheel.

Despite drawing inspiration from Linear, we built everything from scratch. Our primary focus is the AI and task prioritization, which consumes most of our effort. We anticipate that our product will evolve and change over time.

Our aim was not to duplicate Linear, but to build a great product, and incorporating elements of Linear’s UX was a part of that process.

Lawsuit under what law? The general design of a user interface is not copyrightable, although the assets are. If it was sufficiently distinctive it could be protected with a trademark.

Todoist has had this interface for years. It's standard nowadays, like a grid. I really don't get what people see in Linear; it is way overhyped but a polished app.

Here's a side-by-side. This is way past "taking inspiration"

https://x.com/thisritchie/status/1788527859952238598

this was the first thing i noticed.

While I can detect that perhaps you don’t feel like this is a useful feature, this is absolutely a legitimate and useful feature. I use it literally every day with Linear. With Linear you can make a ticket in Slack by clicking the … and selecting “make linear ticket”, which gens out a ticket that summarizes the title using AI and pulls in the conversation that you genned it out from, including future updates. The ai autocomplete/title suggestion, while wrong about 25% of the time, removes a huge mental burden around building tickets. If it’s wrong, I just erase the sentence and type my own summary, which takes about 2 extra seconds. But even the wrong summary usually offers good enough context to be able to write the correct one faster.

As an Ops/SRE guy who deals with constant interrupts being able to quickly spawn a ticket and have it pick up the slack conversation saves me literal hours of rote ticketing bullshit every week.

Our goal is to inspire people to provide comprehensive descriptions of the issues they report, without the worry of making them concise. From our experience, while it's easy to describe things, articulating them can be challenging. Hence, we encourage thorough descriptions first and then we'll help refine them into a clear, well-contextualized title.

Any helpful links to further reading on this? It sounds interesting. I'm sure some of the ludicroucity you're seeing is to do with the wide diversity of companies and industries software developers work in.

CRitical path works well when you have a clear idea of how long tasks generally take. with software its much harder to evaluate the length of the work for something you implement for the first time.

Thank you