10 years of TypeFox: How we work and why it works

This year, TypeFox turns ten.

What started as a focused effort around languages and developer tools has grown into work that’s used far beyond our own desks—supporting products and communities across industries and around the world. Along the way, we’ve learned a lot, built more than we initially imagined, and enjoyed the privilege of doing work we truly care about.

Reaching this milestone is a moment of gratitude as much as reflection. It gives us a reason to pause, to appreciate the trust our clients have placed in us, the open source communities we’re part of, and the colleagues who’ve shaped TypeFox over the years.

This anniversary is also a good opportunity to share something simple but important: how our model works, and why it has been solid enough to support a decade of ambitious, long-lived software projects.

What we do – in practice

TypeFox builds custom software tools for domain-specific work: languages, IDEs, and diagrams. In concrete terms, we offer development and consulting services around language engineering and custom IDEs, based on open source frameworks such as Langium, VS Code, Theia, Sprotty, and the surrounding ecosystem.

We don’t sell licenses or lock anyone into proprietary runtimes. Customers can use the underlying open source frameworks indefinitely and free of charge. To strengthen this guarantee, we’ve transferred our key projects to the Eclipse Foundation, where they are developed under vendor-neutral governance. That means the licenses stay open, the rules are transparent, and anyone—individuals or organizations—can contribute.

All of this work is anchored in one idea: we’re not just integrating someone else’s tools. We’re the inventors and maintainers of key building blocks in this space, and we use them to create tailored solutions that fit into real-world processes instead of forcing those processes into generic products.

How companies work with us

Most collaborations start with a concrete need: a language to formalize expert knowledge, an IDE that reflects a domain-specific workflow, or a visual tool that makes a complex system understandable. From there, the depth of our involvement depends entirely on what our client wants to achieve. Some rely on us for architectural guidance or targeted problem-solving. Others ask us to build prototypes, migrations, or full implementations that integrate cleanly with their existing infrastructure. And a good number choose an ongoing partnership, where we take responsibility for a well-defined part of their toolchain and evolve it together over time.

A defining part of this model is the role of open source. Many of the improvements we make to our frameworks happen inside client engagements. When an organization needs a capability that belongs in the shared foundation, we implement it upstream to avoid pushing workaround code into their product. This keeps their own codebase focused on domain logic while strengthening the ecosystem as a whole. Of course all client-specific code remains confidential and proprietary by default; any publishing of source code is done in close alignment with the client.

Companies also come to us with explicit requests to extend the open source stack they depend on, such as new features in Langium or Theia, or entirely new components that fill a gap we’ve jointly identified. These collaborations are pragmatic: the organization receives exactly the functionality it needs, and the result lands in a well-governed open source project where it can be maintained and evolved transparently.

Why we invest so much into open source

Every engineer at TypeFox has at least 20% of their time reserved for open source contributions or learning. This steady investment keeps our frameworks evolving and ensures we stay close to the technologies we rely on. The combination of customer work and open source work gives us a clear view of what’s missing and what actually moves projects forward.

New ideas grow naturally out of this rhythm. Real-world projects reveal recurring patterns: design questions that appear in different domains or abstractions that would simplify a whole class of tools. When such themes surface, we explore them further and turn them into components or frameworks that solve these challenges in a clean, general way. Many of our open source projects started exactly like this: practical experience distilled into reusable building blocks.

This approach allows us to extend the ecosystem without fragmenting it. Improvements flow into shared projects where they can mature and benefit a broad range of users. And it also means new tools are already on the way—we’ll share more about them later this year.

To our clients, and to those we haven’t met yet

Ten years in, we’ve learned that every project is different. Some teams need a steady partner, others need pointed technical guidance, and many appreciate a mix of both. We’re flexible in how we work because the problems we’re asked to solve are rarely standard—and that’s exactly what keeps this field interesting.

To all our clients and partners: thank you for choosing to work with us. Your projects have given us the opportunity to grow as a company, deepen our expertise, and invest in open source with real continuity. They also allowed us to build the kind of team that thrives on complex challenges and cares about the craft behind these tools. We appreciate the trust you place in us and the straightforward, collaborative relationships that make this work rewarding.

And for anyone exploring a new domain language, rethinking an IDE, or searching for the right foundations for a complex toolchain: we’re always open to a conversation. Tell us what you’re building. Let’s see where we can help.