A Vision for Drives - 1 : Ownership must be a Right!

Image Credits: https://phdcomics.com/comics/archive.php?comicid=1788

This is the first post of my ideations toward Drives (Google Drive, Dropbox, iCloud, etc.). I’ll publish two additional posts in this series;
 
Post 1: An Intro to Data Ownership Concept and Some Problems in the Market (this post)
Post 2: The Vision and its Roadmap
Post 3: Challenges and Conclusion of the Vision

In this post, I’ll walk through some insights and observations that let me imagine a new reality for Drives. I hope the future posts in this series will draw an integral Picture that combines the points made to you.

I was a fan of the Evernote application; it was my reference book accumulated from diverse resources for years. It never became my digital brain, but it was like a hand to me, like a hand of the king. But after 7 years, I switched from Evernote to Upnote. (because of some reasons which are not a subject of this post) I wouldn’t expect an easy migration till I noticed that both Upnote and Evernote developed features to export and import. I feel lucky because these apps give me a chance to own my data.

Data Interoperability

Data interoperability -exportability and reusability in another app- is a chance, not a right today. Yes, you can export some personal data (to be informed about which personal data they’re processing) from platforms such as Facebook, but you cannot reuse it in another application. This allows app developers to have a more stickier user audience.

With more friction to switch between platforms, more users will stick to the product. But at the same time, if you’re trying to have an acquisition, you can only earn users who didn’t have a major tool used before, so you’ll not gain experienced ones (and probably the ones who will spend more). The current best practice in product management is to develop a migration feature within your application. Your integration can convert other apps’ exported data, or they can crawl the data from those apps.

I imagine a better world where a product can compete with its design and delightfulness. So, allowing more interoperability by shifting the industry to this approach can be a new reality. And there are some opportunities to shift the paradigm.

Subscription Logic

Subscription-based services became the common practice, mainly after the promotion of Application Stores. AppStore has publicly suggested converting 1-time payment apps to subscription-based ones. And within a few years, users have adopted the subscription idea. This is okay for some service-oriented solutions, but we see more examples that don’t fit the subscription idea well.

There is a slowly rising voice against subscriptions; even someone dared to change the status quo, such as 37Signal Team (working on a platform for 1-time paid apps). The reasons might differ; my reasons were like the above; 37signals’ reasons are here.

Blockchain

One of the Blockchain concepts was Distributed Applications (DApps), which envisions a shell-like software that doesn’t share any data by itself but fetches from and writes to the blockchain. Even more, they hypothesized some concepts like universal social media apps, which comply with a universal protocol for social media on the blockchain. These apps will be like shells; there won’t be different social networks like Instagram, Facebook, or X, but one network and client apps. In the early days of Twitter, there were many Twitter clients, but they were just a shell. They were the apps that just didn’t own the Data Source. They added many functionalities with useful User Interfaces and displayed data differently. So, it was delightful to use these apps.

A typical application can be analysed under 3 layers; Presentation, Business (Logic) and Data Layer

https://www.guidanceshare.com/wiki/Application_Architecture_Guide_-_Chapter_9_-_Layers_and_Tiers

So “Data Interoperability” means a separated, abstracted, and externally managed Data Layer for all applications. iCloud, Google Drive, and more can focus on building this system.

iCloud Example

iCloud became the best-established cloud storage and synchronization infrastructure for iOS systems. If you’re an app maker targeting the Apple ecosystem, you won’t need a file storage service; you can utilize iCloud Storage for this purpose. iCloud manages the synchronization logic and handles the errors.

According to the nature of Apple’s sandboxing, they don’t allow full interoperability. For example, you can access Photos data by using Apple’s PhotosKit, but you cannot access Podcasts data. Or you can create a new area for your application. You cannot read from other data sources. But by following the PhotosKit example, Apple developed protocol-like standards to reach some User Data. iCloud can implement this practice more, and to gain more market share, they can add a percentage to the subscriptions to manage users’ data. They can even promote the apps that comply with  Universal Storage. So Apple can;

1. Centralize user data in a secure platform and make its platform better
2. Earn more market share by providing storage and sync logic to developers (with universal platform-agnostic APIs, so even Android and Windows can benefit)
3. Make Sign In with Apple the new best practice for all.
4. Define new standards to innovate more. For example, they can make the Journal with an interoperable data type, like photos.
5. Define a new revenue distribution model like Apple Arcade and Apple One. I would pay Apple more if they stored my app data, and I would pay less for the app.

A Modern Problem: Distributing Subscriptions

As we all face, news platforms sell subscriptions on their own. So, it’s hard to subscribe and contribute to their effort because we don’t follow just one news source. Sometimes, hype topics become international politics, sometimes AI, and sometimes business. So, to catch up with the agenda, we need to follow different sources. Like Spotify, there should be one that merges various sources and allocates the revenue according to the demand. The same applies to the Drives.

Sometimes, you cannot trust a novel application. Until they get used widely, the chances of collapsing the app’s business will make you try it out less. So, if you use it actively, you might lose your data someday if you don’t have a chance from the developer to allow you to export. Also, after exporting, you might not be able to use it.

On these occasions, owning the data according to a common standard will allow me to explore bravely. Even if I cannot find a fully-similar alternative, I might continue with a less but still functioning feature set.