555 karma · joined December 3, 2021
Distribution (specifically maintenance) becoming cheaper will enable those people to compete/provide enough value to customers that larger companies face downward pricing challenges.
Maybe. Doesn't change the fact that software will be more commoditized.
If software switching costs get close to 0 [because data is owned and can be opened by any other app], pricing pressure will get intense. Investors love cloud SaaS because they can rent-seek and extract margins of >80%. It's unlikely that apps that do not own and lock-in customer data can rent-seek to such a degree. If they do that, users will switch to the next best solution.
Users will refrain from paying a subscription if their app version works and they don't need updates. The good old buy-a-license with 1 year of updates will likely make a big comeback. Local-first software, at least in lix universe [0], does not have fixed recurring maintenance costs like running servers. The elimination of fixed recurring maintenance costs will lead to a proliferation of "hobby apps" that are undercut by price/make it free altogether.
[0] https://github.com/opral/monorepo/blob/main/lix/README.md
Edge compute :D Have data distributed "wherever" (client, server) to perform computations "wherever".
Using a video editor as an example: The video editor running locally means videos can be rendered for free with the user's hardware. Great for hobbyists (or a free-tier!), bad for large projects that would take too long to render. Have "edge compute" and hobbyists can use the free-tier while large projects can render on the cloud.
A repository as a file is self-contained, tracks changes by itself, and is, therefore, free from vendor lock-in. Here is my draft RFC https://docs.google.com/document/d/1sma0kYRlmr4TavZGa4EFiNZA...
there is no value in a cloud-based solution that locks users and customers in if collaboration can be solved in the data (file) level. turns out that version control solves collaboration on the data level and is awesome to build apps.
solving version control for files like jupyter notebooks brings collaboration to those files without the need to give up files in favor of the cloud. playbooks could leverage lix in 1-2 years to build a file-based version of their tool
1. the ease of building an app
2. the additional features like change history, ai readiness, etc. that cloud-backends like supabase or firebase don't/can't provide
it will be our job to communicate 1 and 2 to developers in the future. for now, we focus on building inlang.com as the first lix app(s). inlang.com might by itself become the convincing argument to build on lix "oh look how they build inlang with lix".
founder of opral here. we seem to have stumbled on an easier and better way to build collaborative apps by leveraging "version control as a backend":
- collaboration for file-based software (a real-time layer can be added)
- data ownership for users and companies because file-based (no lock-in)
- open source like pull request collaboration for design, engineering & co
feedback and questions are welcome. directly commenting on the google doc is enabled
Personal taxation is always your country of residency. If you hold stock in an EU Inc., the capital gains tax in your country of residency would apply.
Every country proportional to the profit they generate and the tax rate they set?
Companies overall EU profit $100M: - France $30M profit taxed at 20% = $6M - Germany $50M profit taxed at 25% = $12.5M - ...
Seems like it "just" needs an accounting system that works across the EU.
We are building a git-like change control system called lix that can store different file formats.
Why?
- file-based software is amazing because of interop and data ownership
- storing a file in change control makes a file collaborative, eliminating the need for "the cloud"
- we can solve globalization of software with an interoperable system of apps
- internal tools rarely (never?) need SEO
- the complexity of NextJS rings alarm bells as infra product. A look at your docs confirms my suspicion https://docs.trycreo.com/core-concepts/server-and-client-com...
That is our problem. Taking a software product global (i18n/localiation/marketing) targets multiple personas and buyers (managers, developers, translators, designers, etc). We started with a dev-focused line but that didn't work for everyone else.
Are product pages clear(er)?
- https://inlang.com/m/gerre34r/library-inlang-paraglideJs - https://inlang.com/m/tdozzpar/app-inlang-finkLocalizationEdi...
we know that we haven't nailed communication yet. one team member is working full time on communication/the website
We got a bug report once that „the website is not loading“.
https://inlang.com/c/svelte and https://github.com/sveltejs/kit/pull/10755
If the development of batteries is so rapid, Rolls Royce not investing in electric engines and doubling down on fuel-burning engines instead could open them up for a book story worthy "disruption".
By the time batteries/electric plane engines suddenly become good enough, Rolls Royce might face themselves in a "why does nobody want our fuel-burning engines anymore" situation that will require multiple years to catch up to electric engine manufacturers. Multiple years of catching up that Rolls Royce might not have at the time they find themselves in the "nobody wants our engines anymore" situation.
Hence, I strongly encourage the author to compile to web components instead of a custom output to increase/achieve interop.
we are in our third (major) refactor because the problem is so complex and new requirements emerge regularly :/