Dear Ed and Modeling PMC.
I'd like to comment on the proposed text for the Eclipse Modling
Project.
As I am passionate in the subject, my mail became long, and emotional.
Thus the conclusions ahead:
Ed: as a friend, in my opinion, the new text is a mockery of your oeuvre,
and if you wrote it out of modesty, as I know you, I would propose, to reconsider it.
The old text (see below) was great!
Now below the long analysis.
I wish you all a very nice WE,
Philipp
The new text:
Also as previously discussed, the website is a disaster area. We need a
landing page with a clear message. I propose the following content:
*Modeling: Faster, Smarter, Better*
The bewildering complexity of modern software begs for a fresh
approach focusing on high-level design, delegating menial tasks to
tools and frameworks.From a concise description of your problem
domain, a complete solution can be inferred.
*What is Eclipse Modeling?*
Eclipse Modeling is an integrated assortment of extensible tools and
frameworks for solving everyday problems.
At its core lies the Eclipse Modeling Framework, a rich abstraction
for describing, composing, and manipulating structured information.
Around this core, onion-like technology layers provide powerful
facilities to address most everything you need.
Up to now we had:
"The Eclipse Modeling Project focuses on
the evolution and promotion of
model-based development technologies within the Eclipse community
by providing a unified set of modeling frameworks, tooling, and
standards implementations."
If you compare the two versions, and consider that "Eclipse Modeling
(Framework)" is
the name of the project, the word "model" is mentioned exactly once.
While the old text makes it clear that
- we focus on "model-based" technologies,
- it provides "modeling frameworks and tooling",
- and ends prominently with "standards implementation"
The new text does not even mention that it focuses on models, it
rather mentions as focus
point "high-level design", whereas the specificaiton phase is not
mentioned at all.
The new text tells it provides "an integrated assortment of
extensible tools and frameworks
for solving everyday problems." No mentioning of tooling and
framework to support the
activity of modeling, as in the last text.
Last but not least, the new text presents the project as a "fresh
approach", that is
"Faster, Smarter, Better". It does not even mention, that we are
implementing leading
industry standards like EMof (implemented by ECore), Mof2Tex
(implemented by Acceleo),
QVTO, OCL, UML2, BPMN.
We all know that the real value between these frameworks is not that
they are fresh or smarter.
The real value is that they implement standards in a pragmatic way,
which are the result of
decades of experience in enterprise computing and interoperability
challanges. All major organizations
like Nasa are heavily based on these standards, and Eclipse Modeling
Framework has done a huge
step forward to unslash the power of open source to make these
standards dominant.
UML2, EMof, OCL, QVTO where only successful thanks to the EMF
Framework. BUT the EMF
framework was only releavant, because it has created this huge
success, and combined the power
of standards and open source.
This is another weakness of the new text: the old text clearly puts
"promotion of model-based development technologies within the
Eclipse community "
in the focus. We should be the ones, showing the rest of the
community that modeling is not
simply another "better" framework for solving problems, but it is
the basis for progress.
The new text tells the project provides "powerful facilities to
address most everything you need".
And the list of reasons why using "Modeling" which sounds at this
point like an abreviation
of the project name "Eclipse Modeling Framework" and not like a
topic is very oriented
again towards sofware.
Here would answer, if someone tells me this are the reasons to
model:
*Why use Modeling?*
?To produce high-quality results quickly.
Not agreed.
The strenght is to be able to abstract from the details of the final
results, and
build like in architecture models, that allow to review
specification and details
before the "high-quality" end result is done.
?To reuse tried, tested, and true solutions effectively.
Not agreed.
Modeling allows to create placeholders for parts of solutions, where
we are looking
for reuse, and to delay decisions on actual usage of software, since
models can be instantiated
and simulated without having to have a full implementation.
?To specify complex structured information concisely.
Not agreed.
There may be much more concise ways, but the advantage of modeling
is to specify the
structure of such information in a standardized, exchangable way,
which is on a higher abstraction
level than than data modeling or programming: references and
parameters can be n-ary,
the containment structure is taken into account, e.t.c.
?To design rich textual and graphical notations easily.
Not agreed.
There may be even easier ways around, but EMF allows to add various
kinds of
concrete notation (textual, graphical, GUI) to domain models,
allowing to separate the meanings of models
from their notations. Further, it allows to persist models both in
XML and Databases, without need to program
the persistence.
?To implement powerful runtime solutions efficiently.
Not agreed.
The real strength is that we provide support to use the same
modeling-frameworks not only at
development time but as well at runtime, and that the need to use
different technologies to specify
the structure of our backend and frontend solutions goes away,
because EMF provides server
component to directly interprete and host processes and data based
on models.
?To exploit industrial standards interoperably.
Not agreed.
Industrial standards interoperability has still a long way to go,
since the very good momentum which was provided
by the convergence of the standards and the Eclipse frameworks is
currently at risk.
The project should provides the basis for making industrial
standards interoperability possible, by continuing
focusing on modeling based on the ECore core, and other standards
implemented by the various frameworks.
I am not against pragmatic solutions, and like Eclipse has
influenced OSGi, EMF has influenced the modeling
standards. But I am against forgetting our roots, and why we are
here.
Regards, Philipp
|