An Architect Twice Over
Erich Gamma arrived at the IBM OTI lab in Zurich carrying credentials unusual for a software tools engineer. He was already co-author of Design Patterns (1994), the Gang of Four book that named and catalogued recurring object-oriented structures — a work that shaped how a generation of programmers thought about component boundaries. That instinct for clean separation informed Eclipse from the start. When IBM released Eclipse in November 2001 under the Common Public Licence and donated the codebase to what became the Eclipse Foundation, it shipped not as a Java IDE with a plugin system bolted on but as a plugin platform — an architecture in which even the Java tooling was itself a plugin. The core runtime knew nothing about languages or editors. Every capability, including the workbench UI and the Java Development Tools, registered through the same extension-point mechanism available to any third party.
That decision was expensive to design and relatively expensive to extend: writing an Eclipse plugin in 2001 required understanding plugin manifests, and a class-loading model with genuine complexity. But the payoff was a stable platform that IBM, then scores of tool vendors, then the open-source community could build on without touching the kernel. The concept of a perspective — Eclipse's named arrangement of panes suited to a given task, such as debugging or Java development — gave users a coherent way to switch contexts without losing the state of either. Eclipse reached a dominant position among Java developers through the mid-2000s, and the foundation model proved durable: the project is still governed by the Eclipse Foundation.
The Argument for a Lighter Core
Gamma joined Microsoft around 2011, initially to lead a developer division in Zurich. What emerged, after a period of internal exploration, was Visual Studio Code — first previewed in April 2015, with its source released under the MIT licence later that year, built on the Electron shell. The architectural premise was an explicit reversal of Eclipse's weight. Where Eclipse demanded a full plugin manifest to add anything, VS Code's extension model used a JSON manifest declaring contributions to defined extension points, evaluated in a separate process that could not crash the editor. The separation of extension host from the UI process was the structural fact that made a marketplace of thousands of extensions safe: a misbehaving extension could fail without taking the editor with it.
The Language Server Protocol, which Microsoft published in 2016 alongside VS Code's first stable release, carried that separationist logic further — language intelligence running out-of-process, communicating over JSON-RPC, accessible to any editor that implemented the client side. The protocol meant that the decades-old problem of each IDE vendor reimplementing autocompletion and go-to-definition for every language could be solved once per language rather than once per editor per language. The LSP specification now lists dozens of language server implementations maintained independently of any editor.
What carried forward from Eclipse was not the mechanism but the principle: an editor is a platform, not a product, and its boundaries must be drawn where extension is genuinely clean. In Eclipse that meant OSGi; in VS Code it meant process isolation and a protocol-defined contract for language services. The surface presented to users changed — VS Code's startup time, its integration with Git, its extension marketplace, and its web-deployable architecture made it feel categorically lighter — but the underlying argument, that the editor's core should know as little as possible about any particular language or task, was identical.
Gamma's two editors between them defined the range of what IDE architecture can look like at professional scale: one a component platform for enterprise Java tooling, the other a sovereign free editor that within a few years of release was the most widely used development environment in Stack Overflow's annual developer survey.