User Tools

Site Tools


Dave Orme muses about agile and functional programming.

My current work emphasizes SOA applications using Scala, Kubernetes, and AWS with a React-based SPA front-end. I'm also interested in progressive web applications and developer tools.


Scala, Clojure, and FP


The Cloud

Data-First Development

Older work

Coconut Palm Software home

Donate Bitcoin:



Kubernetes, Docker, Streaming Data, Spark, Scala, Clojure, OSGi, Karaf, GCP, AWS, SQL


Everything I say here is my own opinion and not necessarily that of my employer.


What can we learn from Visual Editor Project?

April 17, 2007

Several times, folks have blogged (primarily at EclipseZone) about the demise of funding for the Visual Editor Project team and the challenges that leaves us with:

  • Lack of Eclipse 3.3 compatibility
  • No support for new SWT and JFace features
  • No support for Eclipse Data Binding

One thing I think would be productive to discuss out in the open is: “Candidly, what can we learn from the Visual Editor experience?” To get things started, here is my list. If folks want to reply/expand on this, please email me directly and I'll paste followups into the bottom of this message.

  • I'd like to see a much smaller, simpler, more easily hackable code base.
  • The Visual Editor team never managed to fully document its APIs. This prevented a vibrant 3rd party addin market from forming.
  • Without simple 3rd party addins, it's really hard to get outside committers. The lack of committers outside the core team is one primary reason the project is where it is today.

Of course, this is no way meant to disparage the excellent work that the Visual Editor core team did. They wrote some awesome code. But I think it's clear that we need a candid, open, healthy discussion of what we can do better in the future to try to prevent this sort of thing from happening again.

What do you have to add?


blog/what_can_we_learn_from_visual_editor_project.txt · Last modified: 2014/10/17 22:08 (external edit)