And cloud SaaS are enemies of both! After all, in order to have data freedom, you need to have something to open in that other program, and cloud solutions do their best to not give you proper open/save file (and even if there's an export function, and even if everything is actually included in the export, it often isn't followed by import function that could read that export). For this reason, I avoid using cloud Sa…
Absolutely. There are some exceptions though. Github is the obvious one. Dropbox by nature has your data constantly exported. Google for its sins has Google takeout.
Yes. And the first two I use, treating them mostly as dumb pieces of infrastructure. Arguably, the functionality they provide have a crucial ops component that I'm all for paying for someone else to handle it for me. But neither Github nor Dropbox locks me into anything.
Google - yes, web e-mail obviously is similar to the above; as for their office suite, I recently found a good excuse to justify shelling out for a proper Microsoft Office subscription (though I don't like that it's a subscription), and I stick to using the faster, locally-available, file-using, much more powerful (if still proprietary) software.
Interesting to see this. We've taken a similar view for the initial phase of the micro network. Locality is going to matter more and more as we move into the future. Although Cloud still has its place and we don't ignore that either.
You don't have to invent entire new paradigms such as CRDT for this. Unix is all about site autonomy, no-BS tooling, simplicity, and portability. So for your next project, consider Unix/Linux as deployment target during development, and only then deploy it to a cloud-hosted Unix cluster, with a local-first but cloud-hosted DB such as PostgreSQL and standardized middleware such as AMQP/RabbitMQ/qpid rather than provider-specific solutions, or at least use de-facto standard protocols such as s3 and MongoDB (if needed) and supported by multiple clouds. Many people are prematurely committing to k8s and "microservices" but in my experience, even though k8s as such isn't intended as a lock-in strategy, it has the effect of absorbing so much energy in projects (with devs more than happy to spend their time setting up auth, load balancing, and automating things rather than on business functionality), and then still ending up with a non-portable, incomprehensible mess of configs and deploy scripts that it just isn't worth it.
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
Might have something to do with the fact that McNucle is a freaking terrible name.
>It should be fast. We don’t want to make round-trips to a server to interact with the application.
The cloud apps are not slow only because of moving data, but there is also a problem that an average server is fast(16cores CPU + 64GB RAM), but If it's used by let's say 100users, It means one user has only 0.16core + 0.64GB memory. So an average laptop(4cores/4GB) or phone(4cores/1GB) is way faster. Basically people buy billions of transistors to use them only as a terminal to the cloud. Not to mention privacy risks.
A week ago, I did showHN for skyalt.com. It's a local accessible database(+ analytics, which is coming soon). I'm still blown away how fast it is, that you can put tens of millions of rows to single table with many columns on consumer hardware and you don't pay for scale or attachments.
I love this idea. Especially the end-to-end encryption for data that passes through a server to enable the ease of cloud computing without relinquishing data ownership.
It also depends on _who_ owns the data. In an enterprise environment the company usually has a vital interest in the data and on-premise deployments are a good way of retaining cloud computing without giving up data ownership. I'm surprised that more SAAS products don't offer on-premise given the privacy and ownership benefits. The tricky part there is making software that is easy to deploy and maintain, which might be the reason that it isn't done more often.
A product like Grammarly that allowed on-premise deployment would side-step a lot of the issues with sending all that data to a third party. I can't imagine a law firm ever being able to (legally) sign up for that.
Those 7 points remind me of the Syncdocs https://syncdocs.com app which ticked most of them. Using an encryption app and Dropbox will let you do the same thing, too.
Today's SaaS world is largely economically opposed to the idea of data ownership. It's a lot easier to make money by renting people access to their data. The problem is not inherently technical. The solution must address the fact that the software businesses favor cloud solutions and other systems that make it difficult to stop spending money
Yes, this is it. We went from local, to local infrastructure/IT, to cloud services in which data is mixed with other data and ownership is nebulous. The business as you say, favours this, because the 'downsides' of the model are more on the side of risk (your data leaking, losing rights to your data, your data being 'sold' etc.) - which we don't like to pay for until it's too late. Unless there are 'big scares' or re…
If Equifax or even Ashley Madison leaks didn't cause any shift in the software culture, I'm having doubts a breach of Salesforce or G Suite would.
It’s strange that Evernote is omitted from the list - it is a great example of local-first app. Their recent-ish history, when the their free tire become limited to only syncing a few devices, illustrates that even if software is fully local, and supports open formats, having the functional cloud matters, a lot.
I love Evernote and I use it daily, but Evernote lacks end-to-end encryption, which is a pity. I store lots of information in that app and I would be more reassured if I knew that it is only me who can read the data. I would even pay more in order to have that kind of encryption. I think that no current feature of Evernote would be affected by encryption as text recognition in images can be done at the client level.