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.
Today, the landscape is fundamentally different. Hardware is abundant. Established open formats exist for most common data types. Version control, indexing, and sandboxing are mature technologies. The barriers that stopped the 1990s attempts are largely gone.
Lesson: Don't dismiss an idea because previous attempts failed. Examine why they failed and whether those conditions still hold.
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.
Ideal must be usable from day one, even before a rich ecosystem of integrated applications exists. The desktop should work as a competent file explorer on its own. Each integrated application adds value incrementally. Users should never face a moment where the system is less capable than what they had before.
Lesson: Design for incremental adoption. The system must be useful at every stage, not only when fully realized.
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).
People think in terms of folders, documents, and spatial organization — not triples and ontologies. Ideal uses typed folders as its organizing abstraction precisely because folders are already universally understood. The type system adds capability without adding conceptual overhead: a folder that looks like an inbox is still a folder.
Lesson: The abstraction layer must be immediately comprehensible. If users can't build a mental model of how the system works, they won't trust it or use it effectively.
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.
Ideal's typed folders operate at the directory level, which is where the user's organizational intent lives. A folder marked as a mail account tells the desktop everything it needs to know: which application renders it and what actions are available. Individual file metadata is still useful, but the folder is the meaningful unit.
Lesson: The organizing unit must be the folder, not the file. That's where user intent and application behavior meet.
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 |
Cross-Cutting Lessons
Ecosystem Matters More Than Technology
Every one of these projects had sound technical foundations. What they lacked — or couldn't build fast enough — was an ecosystem of applications, formats, and developer tools to make the vision practical.
Ideal addresses this in several ways:
- Leveraging existing formats instead of inventing new ones reduces the amount of work needed to support a data type.
- Supporting existing command-line tools as action providers means the ecosystem isn't starting from zero.
- The desktop is useful as a file explorer even before specialized applications are available, so there's no minimum threshold of ecosystem size for the system to be worth using.
Lesson: Technology is necessary but not sufficient. The ecosystem strategy is as important as the architecture.
Security Must Be Invisible
A system where applications share access to user data needs a security model that doesn't depend on user vigilance. Android and iOS have shown that when you ask users to make granular security decisions, they accept everything without reading. The security model becomes theater.
Ideal's security must work through intelligent defaults and infrequent, clear decisions — not through permission dialogs that users learn to dismiss. A music application shouldn't need to ask for access to music files; that should follow naturally from its declared scope. Explicit consent should be reserved for genuinely unusual requests.
Lesson: Security that depends on user decisions will be bypassed by users. Design the model so that the safe path is the default path.