Re: [modeling-pmc] Comment to Ed's new main text for the Eclipse Modelin

[Miles Parker <miles.parker@xxxxxxxxxxx>]

I also have a lot of sympathy for Phillipp's position. However, I lean toward Ed's approach with the caveat that we should mention standards compliance, etc.. as part of the main text. In fact, I'd go a lot further in terms of "dumbing down" (really, smartening up) the message.

My reasoning is simple; I think we need to look at this from a marketing perspective. That means defining the audience we're reaching. Who the adopters that are coming to the page that we want to attract? By and large, the more process-oriented folks already have a good idea of what EMF can do and how it fits into the standards. I know that is arguable; I'm saying this as a % of the people that are potentially coming to the site and potential conversions or whatever it's called in marketing-speak.

The point is that the EMP page should focus almost exclusively on "as an average Java/Eclipse programmer, what can EMP do for _me_?" 

Since Sven spoke up, I'll just say that http://www.eclipse.org/Xtext/ is IMO a strong example of exactly where we want to head with this. (Not to mention other Eclipse projects too.) We need to show more than tell.

At that point, we can be a portal to exploration of all of the issues. Maybe you even have a box that say's "oh yeah, and we make all of these folks happy to.." with a link to a page going through exactly the kind of thing that Phillip is talking about. It's not that I don't think that stuff is important and that we don't need to get it out there, but that doesn't need to be on the main page.

Just my $.02.

On 2012-08-17, at 1:36 PM, Sven Efftinge <sven@xxxxxxxxxxx> wrote:

> Hi Philipp and PMC members,
> 
> I have to say that I like the text Ed proposed. But I can imagine (and your analysis certainly makes that clear) that
> other members of the EMP have a different view on it. I think the underlying problem is that there are very different views on what 'modeling' actually is.
> 
> I mainly see three different categories:
> 
> *OMG's Modeling*
> I see all the standards here backed by the ideas around MDA.
> 
> *Modeling at Runtime* 
> Using EMF as the domain model for software systems. 
> CDO is important here, but also things like data binding and so on.
> 
> *Modeling as API design on steroids*
> Anything that helps building the perfect abstraction for your problem.
> 
> I respect that there are different views and interests and I don't think we should try to find an agreement on a single message. It would just try to be everything to everybody without attracting or informing anybody in the end. I mainly see two alternatives
> 
> 1) We identify the different kinds of 'modeling' (ideally not more than three) and install a front page dispatching to individual subpages.
> 2) We live without a website for EMP and let every project define its message as it seems fit. E.g. the text proposed by Ed could become the text for the EMF project website.
> 
> Sven
> 
> 
> On Aug 17, 2012, at 7:46 PM, Philipp W. Kutter | Montages AG <kutter@xxxxxxxxxxxx> wrote:
> 
>> 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
>> 
>> 
>> 
>> 
>> _______________________________________________
>> modeling-pmc mailing list
>> modeling-pmc@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/modeling-pmc
> 
> _______________________________________________
> modeling-pmc mailing list
> modeling-pmc@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/modeling-pmc