When adopting tools into a company there are many factors considered beyond just the product itself. One of the big ones is trust. I can't imagine many decision makers seeing what you've done and coming to the conclusion that you're a business they can trust to weld to their own. Internally we treat most of them as partnerships, not transactional.
People tend to assume tools are easily swappable in organizations. They are not. It is a major risky decision that has large cost, privacy, and security concerns. Attorneys are heavily involved in the process (ask me how I know).
Now we could make this risky and costly bet on a well established, trustworthy company, run by industry leaders... or we could go with a company who is now well known for completely ripped off the design of the former and slapped some AI into it. Which would you choose?
If you want to build a successful company that tries to take down Jira (PLEASE DO), you can't start like this.
On Jira, I keep hearing the criticism of Jira on this forum a lot, but IMO it's not that bad product. Jira is used by all industries, not just by software management. Making a tool has to be a "silver bullet" for managing any kind of project is not easy. Tell me a better PM tool which is as widely used as Jira.
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.)
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.
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.
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".
Linear also been powered by local first sync since 2019, we have AI features shipped and in the pipeline.
As YC alumni/design founder of Linear disappointed to see that design/ui/product is treated this way and something to completely rip off from other products.
Last 5 years we’ve been iterating on the Linear design and product. We are still a small team. We also like to share how we build and design to improve inspire others.
But this is no inspiration or inspiring.
Just some days ago Garry Tan was talking about how to get founders learn and value design and this is the opposite of that.
(as a founder) I expect YC to understand the importance of iterative design and not throw money out of the window for a snapshot.
Rest assured, we will focus our efforts on these aspects and make sure to rectify the situation.
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.
How does this work?
1. Expanding on the description taking the project meta info or history into account. 2. Adding to the above, come up with feature scenarios and test cases 3. An agent to listen into standup conversations to come up with an updated priority list for PO to approve? 4. Move tickets or suggestions to move tickets to next stage of workflows depending on the state of the ticket? 5. Optimising workflows and suggesting better workflows listening into stand ups, retros etc. 6. Come up with demo list of tickets for team to demo 7. Prefill or suggest topics for retros 8. Come with timeline suggestions depending on history and evaluating the code and designs 9. More on code, come up with architecture diagrams (puml etc) and API contracts dependant on code, tickets and conversations 10. Come up with sub tasks/suggestions after evaluating the description and code base.
Atlassian recently bought Loom and is clearly working to incorporate multimodal video/screen share input through Loom into Jira. We have a smarter Loom alternative (https://augmend.com) that is partially (scrensharing rust core) open sourced and we’d love to help you 1) not use your competitor’s product :), and 2) get you ahead of the Loom/Jira integrations and “better together” developments that are progressing now. https://www.atlassian.com/blog/announcements/atlassian-acqui...
Ymmv with that. I've written a webnovel reader for myself before (never published it because of the obvious copyright issue of scraping the content)
My first approach was a Django SSR app, and it worked great for years. Since then I've remade it several times in various languages, attempting to get the smallest latency possible vs the developer experience.
In my testing, web requests were ultimately faster then indexeddb if the query was essentially pre-computed / simple select (i.e. persisting count attributes with via insert trigger etc). My currently deployed version is java, and it's only role is to extract the userId from the jwt and feed the request params into the query, which is serialized to json by the DB, so the java application simply returns the data as string while setting the application/json media type.
I got full page load (pwa, so cached html/Js) to 8-15ms with that approach, querying the data from indexeddb took upwards from 25ms on all of my attempts, usually 50+ms as the amount of data increased later on
We think indexeddb also evolved in the recent years, but we will definitely keep an eye and keep improving with the available technologies.
Why build Nest on the server when you already have Next for the client?
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.
Do you have a roadmap?
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.
But we will focus fully on opensource there , no external API calls.
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
3. Business Model: We already have a beta version of our cloud service live, where we charge on a per-user basis.Additionally, there's a certain inertia involved in applying for all integrations. These, however, will come pre-packaged in our cloud-hosted solutions via OAuth's.
As this is a recurring issue, we plan to engage with the community for ideas on how to effectively address 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...
JIRA is a pretty large system that does a lot.
Has there been any thought about assisting transitions to happen faster by being able to partially use JIRA as a backend VIA api, and migrate the data?
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
Amazing work!
Edit: Why the hell do people downvote positive comments?? What is wrong with this god awful community - this site desperately needs "Delete Account" I'm done
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.
Nothing fancy, just a bot that can answer questions about tickets and create and edit tickets based upon a haphazard slack conversation. It's an ideal use case for generative AI, but for some reason nobody wants to do this because they're too busy getting genai to write unit tests or cite court cases something else that is highly inappropriate.
I'm not a fan of Jira and avoid it if I can, but it has never reduced my overall "productivity", putting some text in some forms and clicking some buttons just isn't the kind of factor with such an influence in my experience.
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.
It's very common to develop software in response to dissatisfaction with social, organisational, issues. Issues that in turn are impervious to software incentives, that is.
I've seen very simple setups that don't use epics and only have like three ticket types and a handful of states they can be in, like a basic kanban board, and very complex ones where several boards are interconnected and the flow is in part driven by integrations with CRM, git, CI/CD and Confluence.
Most instances I've seen have been quite badly configured in relation to how the organisation prefers to work though, people get small cuts all the time and feel like they need to fight it daily.
I wish we should just set Jira on fire and switch to whatever else, but it's close to impossible when you have hundreds of engineers and PM-s using it. We're stuck with it probably forever.
I see a video on the home page btw
We (at Linear) have spent half a decade iterating to get to this point of refinement in design and UX. To have another funded startup straight up clone it is so disheartening.
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.
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.
Copying the interface is not what I would call "not reinventing the wheel".
Not that you shouldn't have inspiration, but really I couldn't tell it was not linear...
Futhermore, I think it tell that your product lack AI-first design.
To say linear was just a source of inspiration is just not true. Call a spade a spade - linear’s ui is the best in the business so you copied it outright, down to the icons.
If I was to reimplement Excel from scratch but make it look like Excel, Microsoft would still sue the shit out of me.
WPS Office is even more similar in some ways: https://www.wps.com/office/spreadsheet/
FreeOffice is also pretty much like Excel: https://www.freeoffice.com/en/features/freeoffice-planmaker
OfficeSuite feels like a carbon copy: https://officesuite.com/en/sheets
There's also a variety of online offerings, yet someone every single one of them isn't sued into oblivion.
Note: I can personally only endorse LibreOffice, but either way, there's many similar products and that's not necessarily a bad thing either.
Similarities in the layout, flow and overall architecture are fine, this is how you build directions in design. But you take the concept and you tweak it so that there are visible differences. Let's take Slack and Discord for example - I don't know who was first but you can see similarities, however one is not a rip off another. Same with Linear, I think it was inspired by Jira but you definitely cannot say they took it as an example.
The case discussed here is that Tegon copied Linear's interface design (colors, icons, spacings, layout, widgets, etc) almost in a pixel perfect manner, they didn't even bother with introducing their own tweaks found through user feedback. It's a copy and added >we're focusing on AI aspect and don't want to reinvent the wheel< This is not right.
1. We determined that the "my-issues" page needed revisions, so we removed it and are currently reimagining how we can improve this feature.
2. We decided to add a company filter and are in the process of implementing it.
3. We altered some icons and other elements because they didn't align with our vision, like the "Issues" icon.
4. We also removed the title feature from the create issue workflow.
5. We are also adding the feedback module.
As you begin using the tool, you'll discover areas we're actively improving based on our ongoing conversations with customers. We've only been working for 2-3 months, but we're continuously striving to enhance the product based on the feedback we receive.
Not my race, not my horse. However, you have to actively try to ignore the similarities (Excel vs OfficeSuite pictured here): https://imgur.com/a/q0T4uaD It's very much not a clean room design.
> You're basically saying that all of the work on https://dribble.com/ for example, is royalty free and I can copy whatever I see there and make it my own?
Royalty free? No.
Can you copy it, though? If you are in a country that doesn't care about IP or can get away with it, e.g. if what you create won't have enough visibility to get you into trouble, or you're in circumstances where prosecution is unlikely? I don't doubt that a lot of people are doing exactly that. You can probably do whatever you want as long as your risk tolerance is high enough and eventually you don't mind receiving a cease & desist in the mail.
It's much the same with the various attempts at recreating Windows/Mac UI/UX in the various *nix distros out there, or whatever the people behind Wubuntu were trying to do with a very clear financial incentive: https://youtu.be/QQD3yx-JF2E
In my eyes, it's a gray area of questionable ethics, at least in the case of copies, a bit like the various video game emulators, YouTube downloaders, fan servers for games and so on. In some cases you might end up ruining your life due to actual litigation, though. Probably not something I'd try to personally do, but common enough to raise an eyebrow, yet not spark outrage on my part.
> Let's take Slack and Discord for example - I don't know who was first but you can see similarities, however one is not a rip off another.
Is Discord and Slack similar? Not really, not that much. Slack and Mattermost or Rocket.Chat, though? They're quite alike, to the point where someone could take an issue with it, yet there's been no controversy about that: https://imgur.com/a/3n5ssQQ (random online screenshots)
Granted, they also diverge as time goes on, even if the target audience is very much the same.
> The case discussed here is that Tegon copied Linear's interface design (colors, icons, spacings, layout, widgets, etc) almost in a pixel perfect manner, they didn't even bother with introducing their own tweaks found through user feedback.
I wonder if we'll get a lot of litigation around things like that in the future, since companies really care about their branding. Back when half the web looked like Bootstrap, you didn't hear a lot about that, though. Companies most likely won't sue each other for using the same component libraries, whereas the actual UI/UX similarity is probably a scale of sorts, a wide area in the middle is probably just "doing whatever works and what people are used to".
I wonder what the closest copy to Jira is, that'd be like a speedrun at getting sued.
It leaves a bit of a bad taste IMO to blatantly copy a startup that’s working its ass off to create a good product and then releasing it as open source, but I have a hard time imagining you can make this legal. Not a lawyer though.
Copyright doesn’t protect functionality, which would rather be protected by patents. So you cannot say “This UI element functions in this way and this is protected”. It is purely about how it looks, and everything looks much the same these days.
It’s why I’m quite bull on GitHub’s project management software, because they’ve already got the integration and automation stories handled. They just need to catch up with feature parity and UX. The second that they get that, they will absolutely start eating these other companies lunch. And they are getting closer every year
Yes please, tickets that POs spent even less time thinking and writing about.
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.
Unfortunately there’s no clean obvious way to “guess” what the context is under those conditions, but maybe someone can be clever with heuristics to try to do that where they perhaps feed the last X amount of tokens in from slack and do a Langchain-like approach where first the context is summarized in the initial call and then the title is generated from that summary
Often people just provide the title of tickets (“It does not work!!”) and don’t even care about proper descriptions.
The whole idea humans should be prioritizing tasks has been wrong from the start, and indicates a lack of the right information in the system.