61–70 of 243 posts
any marginally successful "local-first" app is going to go and raise $10m in vc, switch to software as a service, and add an enterprise mode that requires user permissions and data access to be managed on the server
I've been doing some work on it over the last few days: https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-b...
I've been trying to document my "local-first" approach to managing photos. I've made it a ways through but am not sure when I'll finish. Posting here since it is relevant. A Pragmatic Photo Archiving Solution: https://docs.google.com/document/d/1JzqT-DJFlS2e8ZC00HrsQITq... It's the culmination of software I've written [1] + a workflow that's resulted from it [2, 3, 4, 5]. [1] Elodie - https://github.com/jmathai/elodi…
it was just the thing I was thinking of building recently as it was getting really tiring to manually organize photos
one extra idea that I had: there's a cool project that would enable offline geocoding[1], which would help get rid of API limits while making the reverse geocode queries almost instant
(the included dataset is pretty limited, but it's not hard to extend from an openstreetmap planet dump)
Earlier quoted context omitted.
> The best part is that many people think that an on-premises version should be less expensive than the online version, and come without a subscription. Which makes sense IMHO, provided they are not expecting any updates to their on-prem installation. It can just be a fork of your current codebase with no new features or warranty. Maybe you can include some terms for critical security updates but that is about it.
But that, unfortunately, is entirely unrealistic. When I discover critical bugs, I can't leave users out in the cold. I believe that the whole concept of "software without support" is fundamentally flawed.
When I select software these are among the list of things I am looking for generally: - file formats that won’t lock you in or are even openly hackable (allows you to automate things) - no clouds that will break the software once it is gone - local storage with custom syncing or backup options - strictly no weird data collection or “We own the rights to your data”-Type of terms So if I get the slightest feeling of a…
While I fully agree with your selection criteria, please consider the other side of the equation, because engineering (and the world) is all about compromises. I am the author of a SaaS app ( https://partsbox.io/ ). I export in open formats (JSON), there is no lock-in, it's easy to get all of your data at any time. But the app is online and will remain so. Why? Economics. Maintaining a self-hosted solution is an enor…
A lot of devs have moved away from that because subscriptions provide better peace of mind and smooth out the income stream, but it's not clear it's really better for users. Certainly they lose some optionality and there's less market pressure on the suppliers to ship big new features that motivate upgrades.
When I select software these are among the list of things I am looking for generally: - file formats that won’t lock you in or are even openly hackable (allows you to automate things) - no clouds that will break the software once it is gone - local storage with custom syncing or backup options - strictly no weird data collection or “We own the rights to your data”-Type of terms So if I get the slightest feeling of a…
While I fully agree with your selection criteria, please consider the other side of the equation, because engineering (and the world) is all about compromises. I am the author of a SaaS app ( https://partsbox.io/ ). I export in open formats (JSON), there is no lock-in, it's easy to get all of your data at any time. But the app is online and will remain so. Why? Economics. Maintaining a self-hosted solution is an enor…
Common sense.
My company built this more than 10 years ago, and nobody was interested. Here's a press release from 2007: https://www.macworld.com/article/1058169/mcnucle.html
When I select software these are among the list of things I am looking for generally: - file formats that won’t lock you in or are even openly hackable (allows you to automate things) - no clouds that will break the software once it is gone - local storage with custom syncing or backup options - strictly no weird data collection or “We own the rights to your data”-Type of terms So if I get the slightest feeling of a…
While I fully agree with your selection criteria, please consider the other side of the equation, because engineering (and the world) is all about compromises. I am the author of a SaaS app ( https://partsbox.io/ ). I export in open formats (JSON), there is no lock-in, it's easy to get all of your data at any time. But the app is online and will remain so. Why? Economics. Maintaining a self-hosted solution is an enor…
A good example are note taking apps. My notes should be private and I want to be able to read them ten years later. For me your product would need to add something valuable to this that a filesystem and a bunch of files that I synchronize myself can't do. As for now there is no note-taking app I found where the benifits outweight the preceived loss of privacy and reliability. The online thing can make sense, but syncing my phone with Nextcloud works even better, so I don't really see why I'd need it.
This is potentially different with an app like yours, because the benefits of using your app vs using e.g. a spreadsheet seem truly tangible. Using JSON and allowing export at any time is a huge plus. Having it a web-only kinda makes sense, as your app seems to be geared toward teams (and any serious parts managment makes a lot more sense when you are not alone).
While the additional work that would have to go into documentation and programming if you were to offer this as a self-hosted variant is non-trivial, from my standpoint offering the option to self-host can also be seen as an act of communicating: "Don't worry, whatever happens to this project, you will not lose the time invested".
I am not obsessed with this kind of reliability, but I just want to avoid the future hassle of having to deal with this, especially when I put a lot of time into it.
Earlier quoted context omitted.
While I fully agree with your selection criteria, please consider the other side of the equation, because engineering (and the world) is all about compromises. I am the author of a SaaS app ( https://partsbox.io/ ). I export in open formats (JSON), there is no lock-in, it's easy to get all of your data at any time. But the app is online and will remain so. Why? Economics. Maintaining a self-hosted solution is an enor…
That's not an unreasonable assumption, right? It's just an extrapolation from how desktop/local software has always worked. Demanding a subscription for something that doesn't, technically, need any maintenance or ongoing costs on your part is a relatively new thing. Yes, of course, people expect a stream of updates these days for security if nothing else. But you could sell a version of your app that's static - urge…
Also, a lot of people seem to forget that even if we pretended that support isn't necessary, just the existence of a standalone version imposes ongoing costs: there is more testing, and the scope of changes that can be made is more limited.
Subscriptions are the only sustainable way of maintaining software in the long term. We can either accept that and move on, or keep pretending we "buy" software that will work forever, and then pay every year for a "major new version", which apart from the fundamentally fictional nature of the deal, results in developers cramming in new and unnecessary features instead of focusing on software quality.
Earlier quoted context omitted.
But that, unfortunately, is entirely unrealistic. When I discover critical bugs, I can't leave users out in the cold. I believe that the whole concept of "software without support" is fundamentally flawed.
Agreed. But if a user agrees to be left "out in the cold", you should allow him to. Given that it is not very costly for you to prepare your software for on-prem, it maybe a win-win for all the parties involved.
I have been asserting exactly the opposite in this thread.