Doug has published a response to an Open Letter addressed to him from Lars Corneliussen. I think Doug did a good job in addressing Lars’ concerns, and where not, to invite discussion. I wanted to add a couple of comments of my own.
First: terminology connected with modeling, code generation and runtimes. Given my background in various modeling efforts at Microsoft over the last ten years, I know of the difficulty in seeming to redefine established terms. We faced a lot of the same concerns when, in 2004, we tried to help people understand the subtle distinctions between modeling with DSLs and using UML. As history showed, in many cases we were not very successful then, though these days (see several entries on Steve Cook’s blog especially this one and this paper from Andrew Watson, Technical Director at the OMG), most people are willing to see how both approaches may combine to bring benefits to developers across the lifecycle.
I for one have been using the term “model-driven software development” (or just “model-driven development” for short) for a number of years (actually going back to my pre-Microsoft years at Texas Instruments during the era of CASE tools). When Jack and I wrote the Software Factories book, we used the term model-driven development to encompass both “model-assisted” and “model-driven” as Doug uses those terms. We saw then, and still do today, that MDSD could involve models that transform to other models, which transform to code and which just “complete frameworks” by transforming into whatever is necessary (including no transformation) to drive a framework at runtime. For example, if I use a transform to build a logical data model, several workflows, and some service descriptions from a set of business process models, I think I’m doing more than just drawing, and I may be doing some code generation and model generation. Which of the three terms best describes this activity?
As I explained in my previous blog entry concerning the DSL Toolkit and Oslo, we are trying to help folks understand the specifics of Oslo in its first incarnation, with respect to pre-existing technologies from Visual Studio (and other parts of Microsoft). This leads us to seek terminology that helps us conduct that discussion, and in cases such as this, involves some subtle distinctions that are tough to differentiate. As Doug says: “when you a birth a new product, naming/terminology is often the most difficult aspect of the process”.
Second: Open Microsoft and Eclipse Modeling Project. I second Doug’s remarks wholeheartedly. I’d especially like to see discussion on relationships between EMF and oAW technologies.