Prior Art

The idea of organizing a desktop around data instead of applications is not new. Several projects have explored this space over the decades, each with different approaches and different outcomes. Ideal builds on their insights and learns from their limitations.

NeXTSTEP and OpenDoc (1990s)

The earliest serious attempts at document-centric computing came in the 1990s. Apple's OpenDoc and NeXT's approach to compound documents both tried to break the application-centric model by letting multiple tools operate on parts of the same document.

OpenDoc allowed different "parts" of a document to be handled by different component editors — a spreadsheet table inside a text document, each handled by its own component. NeXTSTEP's services menu let applications expose operations that could be invoked from any context.

Both failed commercially, but not because the core idea was wrong. The hardware of the era couldn't support the overhead. The tooling for developers was immature. And critically, the ecosystem required buy-in from major application vendors who had no incentive to disaggregate their products.

Plan 9 (1990s–2000s)

Bell Labs' Plan 9 took the Unix philosophy of "everything is a file" to its logical extreme. Every resource in the system — network connections, processes, graphics — was represented as a file in a hierarchical namespace. Applications composed by reading and writing files, and the filesystem was the universal integration layer.

Plan 9 proved that a file-based integration model is technically viable and remarkably powerful. Its failure was not technical but practical: it required a complete break from existing software ecosystems, and the benefits weren't compelling enough to justify the migration cost for most users and organizations.

KDE Semantic Desktop — Nepomuk (2000s–2010s)

KDE's Nepomuk project attempted to add a semantic layer on top of the traditional desktop. It indexed files and extracted metadata, then used an RDF-based ontology (NEPOMUK) to establish relationships between resources — a document related to a contact, a contact related to a project, a project related to a set of emails.

The vision was compelling: instead of navigating folders, users could find and relate their data through meaning. In practice, the system struggled with performance (the RDF store was slow), resource consumption (indexing was expensive), and user comprehension (the semantic model was too abstract for most users to understand or benefit from).

Haiku OS

Haiku (successor to BeOS) is notable for its deep integration of metadata into the filesystem. Every file can carry arbitrary attributes — queryable, indexable attributes that applications use to store and retrieve structured data. The mail client stores sender and subject as file attributes; the music player stores artist and album the same way.

This gives Haiku some of the properties Ideal aims for: data is visible and queryable at the filesystem level, not trapped inside application databases. However, Haiku's model is file-level, not folder-level — there's no concept of typed folders that change how the desktop presents an entire directory. And applications in Haiku remain standalone programs, not integrated parts of the desktop shell.

Comparison Summary

Aspect	NeXTSTEP/OpenDoc	Plan 9	Nepomuk	Haiku	Ideal
Unit of organization	Compound document	File namespace	RDF graph	Attributed file	Typed folder
Integration model	Component editors	Filesystem I/O	Semantic index	File attributes	Views & actions
User's mental model	Document parts	Files	Relationships	Files + queries	Folders + apps
Application independence	Partial	Full	None	Full	Full
Practical outcome	Too early	Too radical	Too abstract	Niche OS	In design