Dr. Miro SpönemannTypeFox didn’t start from zero in 2016. Long before the company existed, much of the team was already deeply involved in the Eclipse ecosystem, building and maintaining Xtext and related projects. By the time we founded TypeFox, we had already earned a reputation for tackling hard problems and turning them into usable, open foundations. Some people in the community jokingly called us the “X-men,” a nod to Xtext and Xtend (a programming language built with Xtext). We took it as a compliment.
What followed over the next ten years was a steady stream of new tools and frameworks. Two themes run through almost everything we’ve built: custom IDEs and domain-specific tooling on the one hand, and language engineering on the other. These are not goals in themselves, but the means by which we crack some of the hardest nuts in custom tooling. From early work on language servers and web-based IDE frameworks to diagramming, extension marketplaces, cloud development environments, and modern DSL tooling, these threads keep intersecting and reinforcing each other—guided by the needs of the domains we work in.
There is one notable outlier in this story of open source projects: Gitpod. What started as an internal development at TypeFox grew into a VC-backed product company with an open-core model and a very different trajectory. In late 2020, Gitpod was spun out as an independent company, and the team split into two. That moment marked a natural breakpoint—both organizationally and technically—and it’s the reason we tell this story in two parts.
When we founded TypeFox in January 2016, we made an explicit decision to change direction and push ourselves beyond what felt safe. It was a deliberate move into unfamiliar territory—challenging ourselves to learn quickly, take on new risks, and still enjoy the work along the way.
From the start, we aimed to do more than simply leverage our consulting network to pay the bills; we wanted to use that foundation to build novel capabilities for developer tools—out in the open. We set out to grow TypeFox as a company that stays curious and inventive, with a strong affection for open source, deliberately taking on challenging problems and creating room for learning and self-fulfillment along the way. That ambition shaped our culture early on and influenced the path our work has taken ever since.
When Microsoft introduced the Language Server Protocol (LSP), it was still unclear whether the idea would spread beyond VS Code. We immediately recognized its potential: a shared protocol could eliminate years of duplicated effort across IDEs and make language tooling portable by default. Our first step was to create a Java implementation of the protocol, which resulted in LSP4J, an extensible binding for both language servers and clients which can also be used for other JSON-RPC-based communication.
LSP4J arrived at exactly the right moment. It gave Java developers a straightforward way to implement or consume language servers, lowering the barrier for entire ecosystems to adopt LSP. Today it is the standard implementation used by many widely adopted Java-based language tools.
Theia started with a straightforward question: What would a modern, web-native successor to Eclipse RCP look like? At that time, no framework offered the combination the industry needed: a clean architecture, a web-first foundation, extensibility at scale, and support for both desktop and cloud deployments. Existing attempts either carried too much legacy or weren’t designed for real customization. So we built a prototype using TypeScript, Monaco, Electron, PhosphorJS, and dependency injection as the technical backbone. That prototype became Eclipse Theia.
Over the next years, Theia grew rapidly through a mix of customer projects, open collaboration, and sustained investment. Ericsson was a driving partner, and other major companies followed: Arm, Arduino, Google, IBM, Red Hat, SAP, and others adopted Theia in their toolchains or contributed directly to its evolution. Theia replaced the aging Che IDE client, became the foundation of numerous commercial and internal platforms, and made it clear that a customizable and vendor-neutral alternative to VS Code was feasible, and that demand was there.
A key milestone was Theia’s move to the Eclipse Foundation, which established it as an open and governed ecosystem. In recent years, the foundation has doubled down on this trajectory: Mike Milinkovich described Theia as the next generation of Eclipse, and projects such as Theia AI, developed by EclipseSource and promoted by the foundation, show how the ecosystem continues to evolve around modern, AI-driven workflows.
We created Sprotty with the goal of delivering fast, customizable diagrams on the web without carrying over the complexity of traditional modeling frameworks. Sprotty features a clear architectural split between the application-specific semantic model and a lightweight view model, combined with a reactive update flow for a clean separation of concerns. This also makes it easy to integrate with auto-layout libraries such as Eclipse Layout Kernel.
Our approach to diagrams is deliberately pragmatic. In many projects, Sprotty is used to render auto-generated views that help users explore complex models through task-driven filtering, progressive expansion, and targeted highlighting. Diagrams are treated as computed projections of richer underlying data, allowing multiple focused views to coexist and adapt to the user’s current task—without forcing manual diagram maintenance.
At the same time, Sprotty also supports interactive and editable diagrams where graphical input drives changes to the underlying model. This makes it a suitable foundation for more advanced modeling stacks, including Eclipse GLSP, which builds on Sprotty’s view model and rendering concepts to provide programmable graphical editors. Across industry projects, Sprotty is used for everything from lightweight visualizations to fully interactive diagram editors embedded in larger tools.
Gitpod began with a simple observation inside TypeFox: code reviews were unnecessarily painful. Switching context, rebuilding local environments, and reproducing someone else’s setup introduced enough friction that even experienced developers cut corners. If workspaces could be provisioned automatically, with configuration-as-code and fast startup, developers could focus entirely on the task at hand. That idea became the foundation of Gitpod.
We built the first prototype around Theia, Docker, and Kubernetes, tightly integrated with GitHub. Once we started using it ourselves, it was clear that this workflow was fundamentally different from local development: every task began in a clean, reproducible environment, and the setup step effectively disappeared. Early adopters saw the same effect, and usage grew quickly. That momentum led to venture funding and the spin-out of Gitpod as an independent company, separating the needs of a global SaaS platform from TypeFox’s consulting business.
By automating workspace provisioning and pushing development environments into the cloud, Gitpod helped define what would later be known as CDEs (cloud development environments). Over time, the company refined the platform far beyond its early prototypes.
In 2025, Gitpod entered its next chapter with the introduction of Ona — a broader remote compute platform designed to support not only ephemeral developer workspaces but also the emerging workload of autonomous software agents. Ona is positioned as the evolution of Gitpod’s core idea: reliable, fast, reproducible compute environments, now extended to serve AI-driven engineering systems that require isolation and full automation.
Open VSX began as a pragmatic response to a hard limitation we faced while building custom tools based on Theia or VS Code: the entire VS Code extension ecosystem was locked behind Microsoft’s marketplace terms, which prohibit access by non-Microsoft IDEs. For organizations depending on open tooling—and for any vendor building their own IDE—this meant that one of the largest communities of IDE extension publishers was effectively off-limits. So we created Open VSX: a fully open, compatible extension registry that anyone could use, host, or contribute to.
When we transferred the service to the Eclipse Foundation, it gained the governance model and neutrality it needed to become a true shared resource. From there, adoption accelerated. Industrial users deployed their own registry instances behind corporate firewalls. Community projects such as VSCodium adopted Open VSX as their default marketplace. A dedicated working group formed around it—with members including Google, Huawei, Siemens, and others—to ensure long-term stewardship and evolution.
The momentum didn’t stop there. AWS publicly invested in strengthening Open VSX as part of the open-source infrastructure relied on by modern cloud IDEs. And just recently, one of the fastest-growing developer tools, Cursor, announced its transition to Open VSX as its extension marketplace—a signal of how deeply the registry has become embedded in today’s toolchains. In just a few years, Open VSX grew from a small but crucial workaround into a global piece of developer infrastructure: a vendor-neutral extension ecosystem supported by major industry players and used by IDEs and products across the world.
When TypeFox entered its next chapter in 2021, the company didn’t reinvent itself, but returned to what had made it strong from the start. With Gitpod spun out as a dedicated product company, TypeFox could sharpen its focus on its core craft: building languages, IDEs, and diagramming tools as a development and consulting partner. Daniel and Miro stepped into leadership, carrying forward a commitment to open source, a passion for helping our customers succeed, and the confidence that a small, highly skilled team can move entire ecosystems.
In the years that followed, that focus became even clearer. Our 2023 rebranding gave visual form to the principles that had always guided us—curiosity, clarity, technical excellence, and openness—and marked a bolder, more deliberate expression of who TypeFox had become.
When we started Langium in 2021, we set our sights on a bold goal: create a modern successor to Xtext for the web and become the de-facto standard toolkit for building domain-specific languages in TypeScript. We kept the ideas that had proven their value—declarative grammars, high extensibility, rich editor services—and rebuilt them on a coherent, web-native stack. The result was a toolkit that integrates naturally with VS Code, Theia, and browser-based editors, generates fast parsers from expressive grammars, and provides a clean, extensible foundation for validation, linking, code generation, and interpretation.
Within eighteen months we reached Langium 1.0, marking a transition from early experimentation to a stable foundation. It offered robust cross-file linking, an expressive grammar language, dependency injection for customization, full LSP support, and the ability to run the very same language implementation in Node.js and directly in the browser. This coherence eliminated the long-standing friction of hybrid Java/TypeScript stacks—one of the core motivations behind Langium. Since then, Langium has continued to evolve steadily with further major releases, reinforcing its stability while pushing the framework forward in performance, APIs, and capabilities.
As adoption grew across industry, open source communities, and academic research, Langium also expanded in scope. Integrations such as LLVM backends for compiled languages and Langium AI for combining DSLs with large language models showed how far the framework could reach beyond classic editor tooling. In 2023, we prepared Langium for the long term by moving it under the Eclipse Foundation, establishing vendor-neutral governance and a transparent development process. This step formalized what had already become true in practice: Langium had grown into a widely used and trusted foundation for language engineering on the web—now more than two million downloads per week, and still growing.
Our work on the monaco-languageclient library began during the initial development of Theia in order to bring full Language Server Protocol support to Monaco Editor. VS Code had LSP built in, but Monaco—the editor component extracted from VS Code—lacked the necessary APIs and wiring. Our TypeScript library filled that gap by bridging LSP messages into Monaco and re-implementing the minimum VS Code API surface required for language clients to function.
Over the years, community contributors and our own team extended the approach into a multi-package toolbox: websocket-based JSON-RPC transport, a unified editor wrapper, and later React components for integration in modern web applications. A major shift came in 2022, when the monaco-vscode-api project made it possible to modularize the VS Code Web API itself—eliminating the need for our earlier re-implementations and allowing Monaco-based applications to reuse far more of the real VS Code codebase. This turned monaco-languageclient into a robust foundation for building full editor-centric web applications with multiple language clients, filesystem views, and other VS Code–like capabilities.
By the time version 10 was released, the project had become a coherent, well-structured toolbox rather than a single-purpose library: a clean separation of concerns, support for complex multi-client setups, and a development experience aligned with modern web tooling. The project is now widely used to integrate existing language servers into browser-based editors, and its examples—from Python with a debugger to Clangd running in WebAssembly—demonstrate how far the ecosystem has come.
Typir addresses a recurring challenge in language engineering projects: implementing robust type checking. It provides ready-to-use building blocks for defining type systems—including primitives, functions, operators, and nominally typed classes—along with default implementations for type inference, assignability, subtyping, and validation. This allows language authors to express typing rules directly, instead of hand-coding complex algorithms from scratch.
The library is written entirely in TypeScript and designed to integrate smoothly with web-based language tooling. For Langium-based languages, Typir offers a dedicated binding that connects type checking with linking, validation, and code generation. As a result, teams can add expressive, user-friendly semantics to their languages with significantly less effort and more consistent behavior.
Open Collaboration Tools (OCT) emerged from concrete requirements in customer projects where existing collaboration solutions fell short. Many available tools were proprietary, bound to a single IDE, or difficult to integrate into custom environments. OCT provides an open, extensible framework for live collaboration that works across IDEs and web-based editors, enabling real-time sharing of code, selections, and cursor positions with end-to-end encryption and support for on-premise deployment.
At the core of OCT is an open collaboration protocol designed for extensibility beyond plain text editing. This makes it possible to add collaborative behavior not only to source code, but also to domain-specific editors, custom views, and browser-based tools. With the Monaco integration, OCT supports live collaboration directly between full IDEs and web applications—enabling scenarios like cross-platform pair programming, interactive reviews, and collaborative tooling that includes both developers and non-technical stakeholders.
If the past ten years have taught us anything, it’s that innovation at TypeFox isn’t primarily driven by roadmaps or trends, but a direct result of our mindset and culture. Curiosity, openness, and a willingness to tackle hard problems have consistently led us to build things that didn’t exist before. There’s no reason to believe this will change.
What does change over time are the technical approaches we use. Custom IDEs, language engineering, and domain-specific tooling remain core parts of our work—but they are means, not ends. The constant is our focus on understanding the specific challenges our clients face in their domains and finding the best possible way to address them.
Today, this increasingly includes AI as one building block in the solutions we deliver. We see growing demand for domain-aware assistants and custom agents that provide more natural, efficient interfaces for domain experts, grounded in the actual structure and rules of their systems. AI won’t replace domain-specific tooling; it amplifies it when embedded thoughtfully.
New projects as well as extensions to existing ones are already taking shape. But I don’t want to anticipate their announcements here. If you’re curious where our path leads next, stay tuned—we’ll be sharing more throughout the year.
The next ten years are already in motion.
Miro joined TypeFox as a software engineer right after the company was established. Five years later he stepped up as a co-leader and is now eager to shape the future direction and strategy. Miro earned a PhD (Dr.-Ing.) at the University of Kiel and is constantly pursuing innovation about engineering tools.
