I want to see good, small, focused tools that are highly polished and (user) tested, and fit into a bigger ecosystem that can be mashed up and adapted on the fly to fit the task you have. Just porting existing mega-apps doesn’t seem appealing at all. They are still going to be as inflexible and overwhelming, and much rougher around the edges.
I think eventually the smaller focused tools will win the market by a wide margin. But for now, there is huge demand for open-source and free alternatives to mega apps. Especially for the education/non-profit sector.
> good, small, focused tools that are highly polished and (user) tested, and fit into a bigger ecosystem that can be mashed up and adapted on the fly to fit the task you have
i wish i could use the shell this way; some of my colleagues could pipe things in between /usr/bin utilities all day for things i'd need a script for
additionally, somewhere in the agent prompt i asked it to maximize app functionality without the user having to sign in. for most office/creative/engineering apps this should work very well in the long term (fingers crossed)
I immediately tried Circuits, because I have a lot of expertise here and realised it was expected: absolutely zero understanding of the product domain. It looks like an EDA package, it smells like an EDA package but an EDA package it ain't.
And I don't want to hear "it's alpha" and "it'll improve over time". The very foundation it is built on is a near zero understanding of the domain.
This is exactly the same as all the sudden Lightroom and Photoshop replacements.
Why should I when there's KiCad on the market? Or even pay for Altium?
Put a usable product on the market from day one or don't bother. There's absolutely no proof you will deliver anything here. This is just slavery to an inferior promise in the name of progress.
I'm not patting this on the head and waiting and expecting it to grow up into a work dog.
shoving all of these vastly different applications into one monorepo does not bode well for them being seriously designed, maintained, and cared-about pieces of software. such is the nature of LLM development, i suppose.
not to mention that there are only three contributors and #2 is claude, although that might be because they just committed a bunch of previously-untracked code at once, i don't care to check.
I feel like you're being snarky but, regardless, I'm curious to hear your reasoning for the first paragraph. being a monorepo helps us share code across 50 different apps without falling into a submodule/dependency hell.
there are other ways to share code than a monorepo, namely independently versioned packages. you say dependency hell but if you're in control of everything you're in the best position to avoid that if you put thought into it. with a monorepo you could actually get worse results in some cases. say i change something in a graphics api for sudoku and suddenly the zoom clone doesn't work. yuck. i only buy the monorepo argument for systems of code that actually need to be deployed in sync, like server/client stuff or larger. iirc google has a massive monorepo for nearly all of their production code because basically all of it works together (server/client stuff, auth, etc)
also a monorepo like this is worse for human interaction, if you care. what if someone only wants to pull and work on sudoku? now they have to get everything else. issues and pull requests are also more annoying to varying degrees depending on use.
What's shared between the "Property Management" and "Photo Studio"?
The UI frameworks already exist, there's 0 reason to share more things between them. That is, unless it has a slopped revolutionary(tm) UI framework #1000.
I like the idea of replacing entrenched proprietary apps with familiar UIs, using AI.
I'm not the first to say that AI is enabling a fracturing of these projects, though. There's this, and also "ArtCraft" I think, which seem to be trying the exact same thing. I wonder if there is still a place in the AI era for separate projects to merge efforts and processes to accelerate the development of quality clones.
Are people not aware that every single one of these already had open source, self-hosted alternatives? Why do we need to add a pile of slop-code knockoffs? Why does it need to be one giant repo? Does this person have any experience building and releasing software that wasn't built and released for them by a robot?
I want to see good, small, focused tools that are highly polished and (user) tested, and fit into a bigger ecosystem that can be mashed up and adapted on the fly to fit the task you have. Just porting existing mega-apps doesn’t seem appealing at all. They are still going to be as inflexible and overwhelming, and much rougher around the edges.
I think eventually the smaller focused tools will win the market by a wide margin. But for now, there is huge demand for open-source and free alternatives to mega apps. Especially for the education/non-profit sector.
There are already open-source and free alternatives for every mega app.
true. we're throwing our hat in the ring too and some people like it, some don't. regardless, more options for everybody...
> good, small, focused tools that are highly polished and (user) tested, and fit into a bigger ecosystem that can be mashed up and adapted on the fly to fit the task you have
i wish i could use the shell this way; some of my colleagues could pipe things in between /usr/bin utilities all day for things i'd need a script for
Pressing "Try it" makes an app load up instantly. That should at least give people who create bloatware some pause.
Thank you for trying them out :)
additionally, somewhere in the agent prompt i asked it to maximize app functionality without the user having to sign in. for most office/creative/engineering apps this should work very well in the long term (fingers crossed)
I tried Document and it complained about font kerning support and wouldn't let me do anything.
yeah, I'm aware. working on it.
I immediately tried Circuits, because I have a lot of expertise here and realised it was expected: absolutely zero understanding of the product domain. It looks like an EDA package, it smells like an EDA package but an EDA package it ain't.
And I don't want to hear "it's alpha" and "it'll improve over time". The very foundation it is built on is a near zero understanding of the domain.
This is exactly the same as all the sudden Lightroom and Photoshop replacements.
Turns out product design is a lot harder than "Make me a product. Don't make any mistakes."
Yes that.
it'll get better over time. Give it some time!
Why should I when there's KiCad on the market? Or even pay for Altium?
Put a usable product on the market from day one or don't bother. There's absolutely no proof you will deliver anything here. This is just slavery to an inferior promise in the name of progress.
I'm not patting this on the head and waiting and expecting it to grow up into a work dog.
> Put a usable product on the market from day one or don't bother.
Tall words for someone recommending KiCad.
KiCad does an ok job. This does not even do job.
KiCad day-one was probably not what you'd call a "usable" EDA suite either.
But it was an EDA suite, not an EDA suite shaped object.
makes sense. some people like this project and are waiting for it to get better. it's a free market, you can use whatever you like most.
shoving all of these vastly different applications into one monorepo does not bode well for them being seriously designed, maintained, and cared-about pieces of software. such is the nature of LLM development, i suppose.
not to mention that there are only three contributors and #2 is claude, although that might be because they just committed a bunch of previously-untracked code at once, i don't care to check.
> shoving all of these ...
I feel like you're being snarky but, regardless, I'm curious to hear your reasoning for the first paragraph. being a monorepo helps us share code across 50 different apps without falling into a submodule/dependency hell.
there are other ways to share code than a monorepo, namely independently versioned packages. you say dependency hell but if you're in control of everything you're in the best position to avoid that if you put thought into it. with a monorepo you could actually get worse results in some cases. say i change something in a graphics api for sudoku and suddenly the zoom clone doesn't work. yuck. i only buy the monorepo argument for systems of code that actually need to be deployed in sync, like server/client stuff or larger. iirc google has a massive monorepo for nearly all of their production code because basically all of it works together (server/client stuff, auth, etc)
also a monorepo like this is worse for human interaction, if you care. what if someone only wants to pull and work on sudoku? now they have to get everything else. issues and pull requests are also more annoying to varying degrees depending on use.
What's shared between the "Property Management" and "Photo Studio"?
The UI frameworks already exist, there's 0 reason to share more things between them. That is, unless it has a slopped revolutionary(tm) UI framework #1000.
for this project, doesn't look like much effort has gone into sharing assets.
Monorepo's don't solve dependency hell. They amplify it.
Reminds me of that recent post saying "we should be more ambitious with software" on the front page.
This certainly checks that box!
All in Javascript? Pass.
Rebuilding the world's software in one repo, all in Javascript, what could go wrong?
Hello, LibreOffice? Anyone?
Nobody got fired for buying Microsoft. [0]
[0] https://www.neowin.net/news/denmark-has-abandoned-plans-to-d...
I like the idea of replacing entrenched proprietary apps with familiar UIs, using AI.
I'm not the first to say that AI is enabling a fracturing of these projects, though. There's this, and also "ArtCraft" I think, which seem to be trying the exact same thing. I wonder if there is still a place in the AI era for separate projects to merge efforts and processes to accelerate the development of quality clones.
Are people not aware that every single one of these already had open source, self-hosted alternatives? Why do we need to add a pile of slop-code knockoffs? Why does it need to be one giant repo? Does this person have any experience building and releasing software that wasn't built and released for them by a robot?
not just person, AI startup! this'll be the one to save the world, i bet
This is fake. No I will not elaborate, I don't feed trolls
You are troll, No I will not elaborate, I don't feed fakers