6 ms·

Local-first isn’t a good model for projects that need to monetize. I’ve given this a lot of thought as well. I think it only makes practical sense for apps that

by jckahn 2y ago

Local-first isn’t a good model for projects that need to monetize. I’ve given this a lot of thought as well. I think it only makes practical sense for apps that exist to serve a public benefit.

braden-lk 2y ago
Yeah at the end of the day, we'll do what lets us keep doing. It does suck that local-first seemingly does not have monetary alignment with public benefit though. A robust local-first app (if we're including syncronization too) is very expensive to make. It's become a bit easier in the past couple of years though.
worldsayshi 2y ago
Yeah it sucks that monetisation and long term user interest is so often diametrically opposed. I would like to make open core software for a living but local first would take away the last reasonable venue for monetisation in those cases.
the_other 2y ago
> Local-first isn’t a good model for projects that need to monetize. It worked all the way through the 80s, 90s, and most of the 00s. It brought Adobe, Ableton and many others to their dominant market positions, despite rampant piracy. It works for a lot of games, still. What’s changed?
- skydhash 2y ago
  Developers shooting themselves in the foot by providing applications for free or 4.99 usd for user growth. Now it feels more like B2B at scale than B2C.
  - jckahn 2y ago
    Thank you for articulating this so well. This is the core of why local-first applications can’t be effectively monetized. Users expect the best things for free or very cheap, and that’s mostly incompatible with the local-first concept.
  - wolpoli 2y ago
    It didn't help that Apple provided the $0.99 price point for iPhone applications when the expectation for programs before was at least $20.
- robertlagrant 2y ago
  For Adobe: they would like your subscription money every month rather than occasional upgrades.
- endisneigh 2y ago
  Did it work? The companies were generating far less revenue.
  - anonymousab 2y ago
    "need to monetize" != Need to enshittify and squeeze every drop of blood from the stone. There's a large spectrum of extreme profits before every getting to that point.
    - endisneigh 2y ago
      Your comparison is disingenuous. In any case, folks are free to try local apps for their business and post results.
  - Zambyte 2y ago
    They're probably generating far less revenue now than if they started to kidnap and enslave people for profit. At what revenue does it start "working"?
    - endisneigh 2y ago
      Humoring your ridiculous comparison, no that’s not true. Revenue maximization given mission constraints is usually the goal. SaaS is simpler, more economic and generally aligns incentives between parties better. There are many things where a one time cost makes sense, though.
      - Zambyte 2y ago
        So you're saying they've reached peak revenue? The best they can do is stabilize? And that's why we've reached a point that it wasn't working but now it is?
        endisneigh 2y ago
        When did I say they’ve reached peak revenue?
- jasode 2y ago
  >It worked all the way through the 80s, 90s, and most of the 00s. It brought Adobe, Ableton and many others to their dominant market positions, [...] What’s changed? To clarify the conversation, "local-first" vs "cloud-based" is inadvertently getting muddied up with revenue models such as single-payment vs ongoing subscriptions. Those are 2 separate concepts. Adobe/Ableton/Quicken desktop software still run locally on the users computer. Adobe Photoshop can save ".psd" files locally on the computer. But they have ongoing subscription fees and if users don't keep up the payments, they lose functionality or stop working. Instead, what people often mean by local-first is "local _data_ stored on my computer as a 1st-class concept". The Single-Source-Of-Truth of data is preferably on my home computer and the cloud is just a convenient replica for backup or sharing. Ideally, the local-first data is also a an open format instead of a proprietary opaque blob. Examples would be local-first Obsidian (markdown files stored locally on computer) -- vs -- Notion (notes stored in the cloud). Or local-first NextCloud instead of cloud-based DropBox. As your examples showed, local-first software can be monetized via subscriptions.
  - dghlsakjg 2y ago
    OTOH, if I need a network connection to verify my subscription status for the software to work in the first place it eliminates one of the main benefits.
- mike_hearn 2y ago
  A bunch of things changed fundamentally in ways that will never go back. As a consequence shrink-wrap software licensing is dead and will never return, sorry :( That happened because: 1. Users expect apps to keep working in the face of platform regressions and policy changes, for "free" (no unexpected extra charges). In the 90s Microsoft went through heroics to make buggy apps work on Windows 95 because if someone bought Windows 95 and an app broke, the user returned Windows to the store and got a refund. In 2024 if Microsoft or Apple ship a buggy OS update and it breaks your app (which they do), the user returns your app to the store and gets a refund. They don't see the platforms changing around them, they just know that your thing worked yesterday, today it doesn't, it's your fault, fix it. This lack of 100% solid backwards compatibility means it's not feasible to sell a program once and let users keep it forever. They won't keep up their end of the bargain and, by the way, governments will always take their side and not yours so don't think you can just wash your hands of such problems via a EULA. Open source apps can get away with this because there was no purchase to begin with, commercial apps cannot. 2. App Stores happened. That means users can leave reviews and star ratings. In the 90s if you sold an app that happened to crash regularly if you pressed a certain combination of buttons, well, maybe three months later a magazine reviewer would notice or maybe they wouldn't. At any rate it hardly mattered unless you had some kind of unusually high level of bugginess and that fact spread through word of mouth. In 2024 if you ship a version with even very obscure bugs users affected by it will immediately start leaving negative reviews. You have to fix this or else your app will become unpopular and you'll lose money, but again, this means a continuous stream of updates which everyone gets, which requires ongoing revenue to pay for it. 3. Collaboration happened. In the 90s networks were weak and most computer users worked alone. If Fred bought Office 2000 and you were still using Word 95, then it was expected that Fred would just know this somehow and also know how to use the "Save as" dialog box to save in Word 95 format. It was also expected that Fred's employer would provide a synchronous LAN fileshare using SMB where Fred could store a file. This was OK because remote work wasn't really a thing, and people tended to work in the same physical building. Because apps did releases so rarely and file writes were all synchronous/SMB supported file locks, this complexity was just about tractable albeit only as long as users had a high tolerance for computer nonsense. In the modern era collaboration is expected to Just Work without users having to phone up their mates to find out what app version they're using. That means everyone has to be on the same version, which means everyone has to get all the updates all the time, which means they all benefit from ongoing work by the company, which means a subscription. Plus we expect to be able to work from anywhere in the world, and from devices that don't support synchronous networked filesystems like iPads which means a custom per-app server farm. Those costs also matter here, see my other comment for why the Dropbox trick doesn't really work that well. You ask why games don't seem to be affected by this. They are affected by this and they adopt a few strategies: • Primarily target games consoles. Way more stable platforms with way fewer regressions. • Adopt subscription payments too. See: MMORPGs. • Keep costs low and hope they can cover them from the sales revenue as the player base expands. • Just don't support games for more than a few months after they launch. That works because games are short-lived things usually. If the game is broken a year after release a few hard-core fans will care but most people have completed the game or moved on, and won't notice.
spacebanana7 2y ago
Depends on who the target customer is. As an enterprise I'd love to pay for a local application wherever possible. Oracle and MS still make billions on what are effectively local database applications. For consumers projects - especially desktop - it's more difficult. Many would rather pirate software than pay a few hundred dollars a year for a licence. However, the advent of highly controlled app stores has mitigated this somewhat.

by jckahn 2y ago

Local-first isn’t a good model for projects that need to monetize. I’ve given this a lot of thought as well. I think it only makes practical sense for apps that exist to serve a public benefit.

braden-lk 2y ago

Yeah at the end of the day, we'll do what lets us keep doing. It does suck that local-first seemingly does not have monetary alignment with public benefit though. A robust local-first app (if we're including syncronization too) is very expensive to make. It's become a bit easier in the past couple of years though.

worldsayshi 2y ago

Yeah it sucks that monetisation and long term user interest is so often diametrically opposed. I would like to make open core software for a living but local first would take away the last reasonable venue for monetisation in those cases.

the_other 2y ago

> Local-first isn’t a good model for projects that need to monetize. It worked all the way through the 80s, 90s, and most of the 00s. It brought Adobe, Ableton and many others to their dominant market positions, despite rampant piracy. It works for a lot of games, still. What’s changed?

skydhash 2y ago
Developers shooting themselves in the foot by providing applications for free or 4.99 usd for user growth. Now it feels more like B2B at scale than B2C.
- jckahn 2y ago
  Thank you for articulating this so well. This is the core of why local-first applications can’t be effectively monetized. Users expect the best things for free or very cheap, and that’s mostly incompatible with the local-first concept.
- wolpoli 2y ago
  It didn't help that Apple provided the $0.99 price point for iPhone applications when the expectation for programs before was at least $20.
robertlagrant 2y ago
For Adobe: they would like your subscription money every month rather than occasional upgrades.
endisneigh 2y ago
Did it work? The companies were generating far less revenue.
- anonymousab 2y ago
  "need to monetize" != Need to enshittify and squeeze every drop of blood from the stone. There's a large spectrum of extreme profits before every getting to that point.
  - endisneigh 2y ago
    Your comparison is disingenuous. In any case, folks are free to try local apps for their business and post results.
- Zambyte 2y ago
  They're probably generating far less revenue now than if they started to kidnap and enslave people for profit. At what revenue does it start "working"?
  - endisneigh 2y ago
    Humoring your ridiculous comparison, no that’s not true. Revenue maximization given mission constraints is usually the goal. SaaS is simpler, more economic and generally aligns incentives between parties better. There are many things where a one time cost makes sense, though.
    - Zambyte 2y ago
      So you're saying they've reached peak revenue? The best they can do is stabilize? And that's why we've reached a point that it wasn't working but now it is?
      - endisneigh 2y ago
        When did I say they’ve reached peak revenue?
jasode 2y ago
>It worked all the way through the 80s, 90s, and most of the 00s. It brought Adobe, Ableton and many others to their dominant market positions, [...] What’s changed? To clarify the conversation, "local-first" vs "cloud-based" is inadvertently getting muddied up with revenue models such as single-payment vs ongoing subscriptions. Those are 2 separate concepts. Adobe/Ableton/Quicken desktop software still run locally on the users computer. Adobe Photoshop can save ".psd" files locally on the computer. But they have ongoing subscription fees and if users don't keep up the payments, they lose functionality or stop working. Instead, what people often mean by local-first is "local _data_ stored on my computer as a 1st-class concept". The Single-Source-Of-Truth of data is preferably on my home computer and the cloud is just a convenient replica for backup or sharing. Ideally, the local-first data is also a an open format instead of a proprietary opaque blob. Examples would be local-first Obsidian (markdown files stored locally on computer) -- vs -- Notion (notes stored in the cloud). Or local-first NextCloud instead of cloud-based DropBox. As your examples showed, local-first software can be monetized via subscriptions.
- dghlsakjg 2y ago
  OTOH, if I need a network connection to verify my subscription status for the software to work in the first place it eliminates one of the main benefits.
mike_hearn 2y ago
A bunch of things changed fundamentally in ways that will never go back. As a consequence shrink-wrap software licensing is dead and will never return, sorry :( That happened because: 1. Users expect apps to keep working in the face of platform regressions and policy changes, for "free" (no unexpected extra charges). In the 90s Microsoft went through heroics to make buggy apps work on Windows 95 because if someone bought Windows 95 and an app broke, the user returned Windows to the store and got a refund. In 2024 if Microsoft or Apple ship a buggy OS update and it breaks your app (which they do), the user returns your app to the store and gets a refund. They don't see the platforms changing around them, they just know that your thing worked yesterday, today it doesn't, it's your fault, fix it. This lack of 100% solid backwards compatibility means it's not feasible to sell a program once and let users keep it forever. They won't keep up their end of the bargain and, by the way, governments will always take their side and not yours so don't think you can just wash your hands of such problems via a EULA. Open source apps can get away with this because there was no purchase to begin with, commercial apps cannot. 2. App Stores happened. That means users can leave reviews and star ratings. In the 90s if you sold an app that happened to crash regularly if you pressed a certain combination of buttons, well, maybe three months later a magazine reviewer would notice or maybe they wouldn't. At any rate it hardly mattered unless you had some kind of unusually high level of bugginess and that fact spread through word of mouth. In 2024 if you ship a version with even very obscure bugs users affected by it will immediately start leaving negative reviews. You have to fix this or else your app will become unpopular and you'll lose money, but again, this means a continuous stream of updates which everyone gets, which requires ongoing revenue to pay for it. 3. Collaboration happened. In the 90s networks were weak and most computer users worked alone. If Fred bought Office 2000 and you were still using Word 95, then it was expected that Fred would just know this somehow and also know how to use the "Save as" dialog box to save in Word 95 format. It was also expected that Fred's employer would provide a synchronous LAN fileshare using SMB where Fred could store a file. This was OK because remote work wasn't really a thing, and people tended to work in the same physical building. Because apps did releases so rarely and file writes were all synchronous/SMB supported file locks, this complexity was just about tractable albeit only as long as users had a high tolerance for computer nonsense. In the modern era collaboration is expected to Just Work without users having to phone up their mates to find out what app version they're using. That means everyone has to be on the same version, which means everyone has to get all the updates all the time, which means they all benefit from ongoing work by the company, which means a subscription. Plus we expect to be able to work from anywhere in the world, and from devices that don't support synchronous networked filesystems like iPads which means a custom per-app server farm. Those costs also matter here, see my other comment for why the Dropbox trick doesn't really work that well. You ask why games don't seem to be affected by this. They are affected by this and they adopt a few strategies: • Primarily target games consoles. Way more stable platforms with way fewer regressions. • Adopt subscription payments too. See: MMORPGs. • Keep costs low and hope they can cover them from the sales revenue as the player base expands. • Just don't support games for more than a few months after they launch. That works because games are short-lived things usually. If the game is broken a year after release a few hard-core fans will care but most people have completed the game or moved on, and won't notice.

spacebanana7 2y ago

Depends on who the target customer is. As an enterprise I'd love to pay for a local application wherever possible. Oracle and MS still make billions on what are effectively local database applications. For consumers projects - especially desktop - it's more difficult. Many would rather pirate software than pay a few hundred dollars a year for a licence. However, the advent of highly controlled app stores has mitigated this somewhat.