To see the future of software, go back to the 1990s. The vision and ambition were there, but the timing and technology were not. In "Jodorowsky's Product Roadmap," I covered General Magic's fate of being ahead of its time when the market wasn’t ready. OpenDoc is another example of an ambitious vision being too early. The value prop was component software, an architecture that fostered third-party collaboration across multiple applications. Take a look at this incredibly ‘90s intro video about the vision.
The vision of OpenDoc
Backed by Apple Computer, OpenDoc was a software framework developed in the reimagined computing with documents at the center rather than applications. Instead of opening a monolithic program to perform a task, users worked within a compound document that could embed modular “parts” from different developers, such as a text editor, spreadsheet, or image tool—all functioning together in the same space. This approach embodied the philosophy of task-based computing, where the user’s goal was the organizing principle, not the boundaries of individual applications (writing a report, creating a brochure, compiling a proposal). OpenDoc promised interoperability, best-of-breed components, and a user-centric workflow.
OpenDoc had five key principles to its approach: component software, compound documents, cross-vendor interoperability, user-centric (not app-centric), and task-based computing.
Component software
OpenDoc reimagined software not as large, all-in-one applications, but as collections of small, modular, and reusable components called parts. Each part handled a specific type of content or function—for example, text editing, charting, or image viewing.
A modern parallel is CodeMirror, an open-source text editor built for the web. Instead of being a full application, CodeMirror is a reusable component that developers embed into larger systems and extend with plugins for syntax highlighting, autocompletion, or collaborative editing. It powers the editing experience in popular tools like Replit, Obsidian, JupyterLab, and HedgeDoc, showing how the component software philosophy lives on today: specialized parts integrated seamlessly into broader, task-focused environments.
Compound documents
Users wouldn’t open a single application to work. Instead, they’d open a document that could contain different embedded parts from different vendors. For example, a single document might contain text from one company’s editor, graphics from another’s tool, and a spreadsheet grid from yet another.
A modern example of this idea is the Jupyter Notebook. In one notebook, you can combine narrative text written in Markdown, executable code cells in Python or R, and live charts or data visualizations generated from that code. The notebook itself becomes the container, pulling together different components into a single, task-focused environment—as OpenDoc envisioned.
Cross-vendor interoperability
Apple’s idea was that developers could specialize in one great component rather than building full, bloated apps. The system would integrate them seamlessly into the user experience, so the user wasn’t locked into a single vendor’s ecosystem. The document itself became the stable foundation, while components from different sources could be swapped in and out as needed.
Obsidian CEO Steph Ango’s (Kepano) file over app concept is a modern echo of the same philosophy. The emphasis is on the portability and longevity of the file, rather than the application used to edit it. For example, I can manage the same set of local Markdown files in Obsidian for note-taking and linking, or in Cursor for writing with AI support, without friction. What persists is the document in its purest form—interoperable, tool-agnostic, and future-proof. This is the promise of cross-vendor interoperability: your work belongs to you, not to the app.
User-centric, not app-centric
With OpenDoc, the document—not the application—was the primary container. Instead of thinking, “Which app do I need to open?”, the model shifted to What am I trying to accomplish? You didn’t have to juggle windows or copy-paste between programs; you worked in a single document environment, assembling the best tools for the job.
Modern workflows echo this shift. In Jupyter Notebooks, for instance, you write text, run code, and visualize results all in one space. In Coda, you don’t open a separate word processor, spreadsheet, and task manager—you build a page that pulls these elements together seamlessly. The user’s intent drives the workflow, and the document becomes the living hub where different capabilities meet.
Task-based computing
Computing in the 80s and 90s was application-centric: you opened Word to write text, Excel to make charts, and Photoshop to edit an image. Each program was a silo. OpenDoc and component software flipped this: instead of thinking “What app do I open?”, the model asked, “What task am I doing?”
Writing a report: You might need text, a chart, and a photo.
Designing a brochure: You’d want layout, vector graphics, and text editing.
Preparing a financial proposal: A text editor framed the narrative, a spreadsheet part provided updatable forecasts, and a charting tool visualized key metrics. Updating numbers in the spreadsheet would automatically update the chart and text references in real time.
Creating a multimedia lesson plan: A teacher could combine typed notes, a diagram component, and an embedded video player part—all arranged together in the same document—so students had a unified learning artifact.
Drafting a newsletter: A writing component managed the body text, an image editor placed photos, and a formatting part handled layout and typography, turning what once required juggling multiple apps into a single, task-focused flow.
Instead of switching between apps, the document itself became the workspace that pulled together the tools needed.
The core idea was that the user’s intent (e.g., “make this sales proposal”) should drive the computing experience, not the constraints of application boundaries. Components—each specialized in one thing—would come together around the task. The task becomes the atomic unit of work.
Despite its forward-thinking vision, OpenDoc struggled to gain adoption. It was resource-intensive for its time. The average Mac had 2 megabytes (you read that right), and OpenDoc required 2-3 times that much. In addition, developers were hesitant to build parts instead of full applications. Users often found it confusing compared to familiar app-based workflows. Coupled with Apple’s financial struggles and strategic reset in the mid-1990s, the project was deemed too costly to sustain.
When Steve Jobs returned in 1997, he famously said OpenDoc was "a technology looking for a problem." He canceled it, leaving the initiative as a short-lived but influential experiment in modular, component-driven computing.
Applying today's concepts
OpenDoc was ahead of its time, but today’s ecosystem of MCP servers, AI agents, and APIs represents a modern revival of its philosophy. Instead of vendors shipping monolithic apps, we now see agents orchestrating modular services—pulling structured data from MCP, calling APIs for specialized functions, and composing the results into a unified workflow.
Much like OpenDoc’s vision of compound documents, the document or task itself becomes the container, while interchangeable parts handle the work behind the scenes. With this shift in AI-driven interaction, the concepts of OpenDoc may yet be resurrected—not as software parts on a desktop, but as intelligent, distributed components stitched together by agents.
Let’s look at some examples:
Market analysis: An agent queries a Snowflake MCP server for sales data, hits the Crunchbase API for competitor funding rounds, and generates live charts in Coda. The result is a single document with numbers, visuals, and a narrative summary.
Product landing page: The agent drafts copy in Notion, pulls brand assets via a Figma API, and optimizes metadata by calling an SEO MCP plugin. Everything comes together in a shareable web preview.
Investor update: An AI agent pulls metrics from Stripe’s API for revenue, Linear MCP server for product milestones, and Google Slides API to assemble the deck—delivering a polished draft that’s task-ready.
Trip planning: An agent uses the Amadeus flight API to book flights, queries the OpenWeather MCP server for forecasts, and integrates with Google Maps API for activities and routes—outputting a dynamic itinerary in one place.
This brings OpenDoc’s 1990s vision full circle: instead of vendor parts embedded in a document, we now have agents stitching together APIs and MCP services, with the task, not the app, at the center. Mark Twain once said, "History doesn't repeat, but it does rhyme." Perhaps with the technology of the AI era, the concepts OpenDoc stood for decades ago may once again be relevant and viable.
Hyperlinks + notes
Related
OpenDoc — A Possibility in the Computing World Suppressed by Steve Jobs
OpenDoc → Blog post by Greg Malentic, the first Product Marketing Manager on OpenDoc
What I read
Notable Improvements to Coding Intelligence in Xcode 26 Beta 71
‘ChatGPT for Doctors’ Startup Considers $6 Billion-Valuation Investment | The Information
AI Isn’t the Problem—We Are | Mia Blume
Google goes bananas, Kling start & end frames & Midjourney x Meta partnership 2
How we restructured Airtable’s entire org for AI | Howie Liu (co-founder and CEO) | Lenny Rachitsky
Hype links
We're hiring Designers at Atlassian → ICYMI: My blog post about one year at Atlassian and why I’m excited about the opportunity
Secrets to Successful Agents: Atlassian’s Strategy for Success
I wrote this two years ago, and there is still so much to innovate on the application layer.
Waiting for AI's pull-to-refresh moment
There is a gesture on the iPhone that long-time mobile users are familiar with that have non-native origins. If you open the official Mail app on the inbox view, you can "pull" the interface down and the app will refresh with more emails. This is known as "pull-to-refresh."
AI in Xcode, finally!
Nano Banana might be the best name ever