Data Ownership and Accessibility is a question of high importance for both our users and us, one we take very seriously.
The fundamental goal of Craft is to help you think, write and communicate better. All of these activities involve processing and managing your data. This is such an important topic that we wanted to share how we think about this, as well as communicating our guiding principles in this area.
Physical vs Practical Ownership
When we look at this topic, we see two areas which determine the level of quality a product or service can provide:
- Physical Ownership – where your data is stored, being able to access the full data via export or APIs
- Practical Ownership (Data Accessibility) – what can you do with your data and how hard is it to do Factors include:
- Ease of data access across platforms (OSes, Mobile, Desktop, etc.)
- Reliability of data access (What happens if service goes down / unavailable)
- Ease of transferring data across systems / products
- Compatibility – Ease of accessing and modifying your data with tools other than what the service provides
- Multi-user access & Collaboration – ease of sharing your data with others
It is important that a product can address both aspects of Data Ownership, otherwise, they impose strong limitations on either the privacy or accessibility (and hence usability / value) of the data they store.
Yet we see very few, if any, pieces of software which address both these areas adequately.
Addressing both at the same time is hard – and often not desirable
By definition, there are strong tech challenges in addressing both, i.e., sharing and platform availability is easy if data is stored on servers. At the same time, it is extremely challenging, if not impossible, to do so when the same data is stored on the user’s computing devices. Note that encryption also isn't a magic bullet, as while it adds a strong layer of security, it doesn't address ownership and also introduces new challenges regarding accessibility.
As of this being a hard question, most products either err on the side of ensuring physical ownership is in place (and provide accessibility via commonly used formats such as plaintext or markdown), or they just skip thinking about this topic at all and hope that convenience of multi-device sync and access is more important for users, than ownership. Which is typically the case, until they are locked out of accessing their data at the level they need, for whatever reason, such as server downtimes, migration to other tools, etc.
In reality, most products / companies are perfectly aware of these questions - but look at it from a moat (lock-in) advantage vs a value they’d like to provide for their customers.
Features vs Foundations
Working on Data Ownership and Accessibility is what we call foundational work, meaning it’s a lot of work in exchange for small visibility. Users often don’t notice this until the point they desperately need it, which might be months or years after their initial engagement. It rarely drives direct signups or revenue. At the same time, the core principles impact every bit of product development, meaning it’s extremely hard (often impossible) to backward implement it.
Startups typically ignore this question, as their focus is on shipping features. If the product becomes a success, there is little to no incentive to change the underlying principles and take on new constraints of this magnitude.
Deep work on foundations goes against the core startup principle of shipping an MVP. As customers, we just have to get used to giving up either practical or physical ownership of our data.
This is wrong.
Our Take & Values
For us at Craft, data ownership and accessibility is a foundational value and has been so since we wrote our first line of code. It’s something which is also extremely costly for us to do right; over 50% of our capacity is dedicated on working purely on this, at a time where we are bombarded by feature requests, or viewed as inferior due to the absence of some feature or other, while other products already "have this."
If we were to drop this as a core principle, we could likely grow faster and deliver more features, but it would come at a degradation of our users’ ability to practically own their data.
Of course, we are not where we want to be yet, but with every week we are getting closer to achieve our goals.
Craft Data Ownership and Accessibility Principles
Below you can find our core principles which guide us through the implementations of both our foundations and new features. We don’t assume these to be complete - and are continuously reviewing if we are missing any aspect. If you have suggestions to extend these, we’d love to hear from you at email@example.com.
Your Data is Always Available
From start, Craft has been offline-first. Meaning we store all your (textual) data on your devices as well as in the cloud. You can access & edit even if offline, and changes will sync back once you have internet connection. This means even if our servers are down or inaccessible, you can still use (read, write, export) your data.
Your Data is (practically!) accessible on Any Device
Web apps typically provide platform-independent basic accessibility - however these are far from being practical. Often mobile / touch is an afterthought, resulting in a level of accessibility which is both undesirable and/or is limited regarding feature set.
With Craft we took the approach of building mobile-first. Meaning we won’t ship features on desktop as long as we can’t build this for mobile - ensuring mobile/touch platforms are just as powerful as their desktop counterparts.
Right now we satisfy this principle on the Apple ecosystem. With the launch of our web editor (estimated 2021 April) we will push forward with this, and hope to release an Android product later on as well.
You can decide the tradeoffs you make
As we’ve discussed above, it’s likely impossible to solve all aspects of Data ownership & accessibility with one solution. In some cases you’re ok with more limited ownership in exchange for increased accessibility (i.e., real-time collaboration), in others not. We give this choice on a case-by-case basis in our hands - rather than deciding ourselves.
We’ve just launched our External Locations feature - which allows you to specify the physical location of your data - and sync it (if you wish to) with a provider you trust. This does expose limitations of web share, collaboration and speed of sync - but if these are important, we have options which enable these. The choice is yours, and you can switch between these any time.
You decide where and when you want to move your data – and we help you do it
Your data is yours - and we empower you to exercise your rights to it. When moving your data most products treat you as if you were breaking up with them. They “give you” something (either their custom format or a significantly degraded simple version of your data), then effectively say it’s your job to do anything else with this.
At Craft we do this differently - we spend lots of time and testing ensuring that you can move over your data with minimal feature loss & friction to other (competing!) products. We don't want to break up with you - we want to help you make that transition.
At the core of this is the principle that your data is yours - and that implies taking it with you wherever your workflow needs it to be taken. We are far from being perfect here, but every week we are adding new integrations and widening your options.
Your data is accessible outside Craft
This principle effectively means that you shouldn’t have to install Craft in order to interact with your data you’ve created in Craft. This is the area where we have the most to deliver - and we’re making progress.
There are two distinct aspects in this area which we are actively working on:
- Your Data in the Cloud can be accessed and modified without a Craft product - meaning we will provide you with strong APIs allowing you to access and modify your data.
- Your Data on your disk can be accessed and modified without a Craft product - This is a bit more complicated. We will do the following actions in order to satisfy this:
- Right now our on-disk storage is based on a JSON file. It's the first step, but this makes it error-prone / hard for you to directly open and modify. We are working on moving to a markdown-based version - (we’ll need to extend markdown to avoid feature loss) - meaning you should be able to open and easily edit with any text editor.
- We will provide open source converters libraries which can convert our on-disk format to a variety of options (similar to what we have in our apps for export options) - enabling you to convert / export your Craft data without our product.
- We will provide strong documentation and open source libraries for parsing and modifying our file format - meaning you can build on top of these if you need to convert to a specific format we don’t have covered.
We know we still have lots to deliver to reach the state outlined above - we also believe our history of consistently addressing these across our releases shows our commitment in this area. These are not features though we tick off once as done - these will require continuous investment in developing and refining these.
One related this topic which often came up when talking with our users about these topics is the ownership of the Craft app - i.e., adding a one-time payment option. In order to both keep aligned with our values above and be able to deliver these, we don’t see this as a viable path currently. Our incentives have to be aligned with best serving our users in the long term. Focusing on a single, one-time payment skews this into focusing on new users vs existing ones.
It also gives our existing users the power of keeping us accountable (you vote with your subscription) - and allows us to continue to invest and execute on these foundational developments.
Our goal is to build a sustainable business which can continuously deliver on these principles - and we hope many of you will join us on this journey of treating & building towards Data Ownership and Accessibility as a core value.
The Team @ Craft