Marcin Wichary’s post is short — a quoted Mastodon thread, three bullets, and Jef Raskin’s Three Laws — but it names the failure mode no amount of test coverage catches. David Chisnall had used vim for over twenty years. One of the features he leaned on was persistent undo, which survives crashes, reboots and major version upgrades, and which he had used to recover something deleted a week and one reboot earlier.
Then he tried NeoVim, and the undo data was gone:
- NeoVim changed the format of the undo files and did not upgrade the old ones
- It did not use a different filename for its own undo files
- It noticed the existing vim undo file, deleted it along with everything in it, and replaced it with one vim could not read
- Because the name was shared, undo was broken in vim too — not just in the editor that caused it
He raised an issue. The response was that the persistent undo format is unstable and that users should not rely on data being preserved in a feature explicitly called persistent undo. It had changed once, and would probably change again.
His conclusion is the part worth keeping: breaking persistent undo is a bug he could forgive, but “the attitude that just because something is a persistent file on your filesystem that contains data that you might want is no reason for their program not to delete it meant they had no concept of a duty of care to their users.”
Raskin’s Three Laws, from The Humane Interface (2000), are the frame:
- A computer shall not harm your work or, through inaction, allow your work to come to harm
- A computer shall not waste your time or require you to do more work than is strictly necessary
- An interface is humane if it is responsive to human needs and considerate of human frailties
The distinction that does the work here is bug versus policy. A format change is unavoidable, and a migration that destroys data is forgivable as an accident. What the reply converted it into was a standing position on the user’s data — and that is a much larger surface area than a defect. There was also no technical constraint forcing destruction: preserve, migrate, or at minimum write under a new name were all available, and the choice to overwrite the shared filename is what let the damage escape the fork.
Wichary names the second-order effect rather than just the grievance: “I can see how ‘It had changed once and would probably change again’ can be such a powerful feeling.” That is a prediction about future behaviour, and engineering trust is exactly the pile of accumulated predictions. One observed violation is enough evidence — the user does not need a second incident to leave.
Migrations, format changes, and teardown paths are where a duty of care is actually tested, because there is always an easy destructive option sitting next to a slightly harder non-destructive one. Raskin wrote the rule down twenty-six years ago, and it still reads as a specification rather than a sentiment.