Open Source Doesn't Ensure Portability

Open source matters less than the layer where lock in actually happens. In internal tool builders, lock in sits in the app schema, widgets, permissions, queries, and workflow logic that are defined in the platform’s own model, not in whether the hosting code is visible. Appsmith’s open source approach clearly improves self hosting, extension, and cost control, but apps built inside Appsmith still depend on Appsmith specific components and runtime, much like Retool apps depend on Retool.

• Appsmith’s own framing of open source is about self hosting, security, and the ability to add missing connectors or widgets. That makes the platform more inspectable and modifiable for engineers, but it does not by itself turn an Appsmith app into a standard React or plain web app that can be lifted out and run anywhere.
  2 sacra
• The real alternative to platform lock in is building the tool directly in React or another standard framework. Appsmith explicitly says one of its biggest competitors is React, and Retool research similarly points to engineers building internal tools from scratch as the core substitute. That is the more portable path, because the app lives in general purpose code instead of a vendor specific builder.
  2 sacra 3 sacra
• This is why open source internal tool builders usually win first on price, self hosting, and developer trust, not on perfect portability. They can pressure proprietary vendors from below, but they still ask teams to accept a low code abstraction layer in exchange for faster delivery.
  1 sacra 2 sacra 3 sacra

Going forward, the winning products in internal tools will be the ones that narrow the gap between speed and control. The more these platforms let teams drop into normal code, reuse existing codebases, and avoid rebuilding workflows when they migrate, the more credible their portability story becomes, and the harder it is for pure proprietary builders to defend premium pricing.