Hacker News Reader

Comment by 600frogs | Hacker News Reader

For the vast majority of users, isn't having solid export options enough, or even better than this? Your average non-techie isn't going to want to configure each app to get syncing with NextCloud or Dropbox working just right, they just want to perform a task with the app and move on with their lives, regardless of where the data lives. And with an export option, if the app dies, you've still got your blog posts or pictures or drawings or whatever it is you were using the app for.

I think being in this bubble of working in and thinking about tech 24/7 can often make us miss the point - these apps are just meant to be tools to do a task.

View on HN

No, because exporting is not automatic. Most users won't do it.

It's true that most users don't want to configure remote storage for each app. That's solvable though. There should be a way to store your remote storage preferences and just give each app permission to store there in one click.

"Just make it one click to store it in a wide selection of remote storage options" is easier said than done. From the standard user's point of view, they don't need to be reguarly exporting, they can just use that option if they want to change apps or if the app itself is at end of life.

I think the idea is also to prevent the centralisation of data. Because then, the entity that owns your data can create service plans to expose sections of it. The biggest example is LinkedIn. They charge a ridiculous amount of money to just share someone's job preference - open to work, etc. Paying for a smart aggregation or filtering or any meaningful transformation of the data is acceptable. But not for just sharing the raw data when it is user generated.

I have some vague plans around building a job portal just for startups looking to hire ex-startup founders where the data is not owned by my platform and freely available for everyone to leverage as per user preferences.

Maybe yes? I’m not seeing anything on this page that describes the intended audience. I know some people care about data privacy, so this seems like it’s for those folks.

I’ve been thinking a lot about the difference between a product and a project. I’m launching an open source project and we need to make it a bit of a product, but I’m hoping to maybe grow a following on patreon or open collective so we don’t have to focus on selling things directly.

Anyway this seems like a cool open source project that might not be trying to be a “product” for the masses.

If you're doing trivial things, or things where the data is the content itself, then none of this matters and you would be right. However, if the data is something more "meta" or is tied to the product itself, it becomes a bit trickier. If the app is not just a tool, but the whole workflow of a team or organization revolves around a workflow the app provides, it can be tricky, because the data is not just the content, but the result of the workflow.

Just imagine. You use Duolingo to learn a language and it shuts down. What do you do? What's the export format. Will the new product have the same levels / trees/ etc? Very unlikely. You'll have to start all over again. It's not about the raw data, it's about the data that your work has generated.

If you're doing machine learning, then there's the raw data, but there's also all the other data resulting from your hard work: training jobs, experiment tracking, parameters and artifacts and metrics, models.

The question becomes... First, how important is your product in the user's life? If it's important, they'll rely on it a lot and use it a lot to do things that are important for them, or for their organization.

Then, the service needs to provide export options and send you a shutdown notification. These are not always true but, assuming they are, you'll have to scramble to exfiltrate your data.

Then when you exfiltrate your data, it's an export. You'll have to find another product or service, and then somehow hope you can import that data to the new product, and then set up another workflow.

And here I'm talking about consumer products. For enterprise, there are many parameters including who the vendor is, procurement, team size. Meaning if you are Google/Amazon/Microsoft/etc, then a lot of people will treat you like a utility that will continue to be there, even with the track record of some of these of shutting down products and services (how many products has Google shut down over the years).

Look at this thread[0] I posted about our machine learning platform and the conversation that followed. The person objected that as long as it wasn't open source, they wouldn't use it. But digging a bit deeper, it turns out what they wanted wasn't really open source, but open source was one solution/implementation to their underlying problem. Trust you'll be there or control.

- [0]: https://old.reddit.com/r/MachineLearning/comments/kolobf/p_c...

I'd argue that if the data is that specific to the app (e.g. which trees and courses of Duolingo you've completed), then if the app dies, the data is irrelevant. Either the data is useful outside the context of the app, in which case it tends to have standard formats (.png for images, .md for formatted text, etc), or the data is not useful outside of the context of the app (e.g. Duolingo) in which case the data is no longer of value and can be discarded, as no-one is going to be able to offer the exact same courses and trees and in-app cosmetics and gems etc etc etc.

It's true that the limited period of time between end of life and servers going offline may be a problem, but that tends to be a long period of time (3-6 months in general from the services I've used that have shutdown).

As I said, the examples you chose are for the simplest use cases, and fungible applications/features for which the raw data is pretty much the whole thing and having a database dump is enough.

Valuable applications more often than not simplify complex things or do hard things behind the scenes. Their value is in the workflow/experience or the processing that takes place on the data, including APIs and integrations to unlock users' creativity.

>It's true that the limited period of time between end of life and servers going offline may be a problem, but that tends to be a long period of time (3-6 months in general from the services I've used that have shutdown).

Again, have you used these as an individual relying on them lightly, or heavily, or as a business/organization where your work relied on these? Have you used them as a user, or as the person who was involved in making the purchasing decision for the whole team/organization?

The only example you gave for app such as you describe was Duolingo, for which I pointed out that the data is useless outside the context of the app.

For business applications, the conversation may be different, but for the consumer ("average non-techie" as the original comment said) I believe what I said holds true.

No configuration needed when using iCloud

Reply on news.ycombinator.com