Hi David,    
It's    great that you're thinking of this.  Boris, McQ and I were discussing    something similar just the other day and to be honest we were really    struggling. 
With respect to    what you have below, this is the first we've used the word "Cloud".  It's    pretty trendy today so maybe we should, not sure. I will note that at first    you're saying how we're extending the reach of the platform (good), the second    is a discussion about adoption of technologies.  The problem with the    latter is that they are only as useful as the advantages they provide, so    saying we'll evolve the architecture and adopt technologies ... to what    aim? 
My belief is that    we need to speak in terms of practical advantages so that a company will see    real benefit in e4, either in terms of reduced application development cost,    integration with a new breed of applications, or ability to reach new    audiences by targetting the web without having to completely abandon their    Eclipse investement.  If they see benefit, they may be will be willing to    spend some developer resources contributing.  Thus that value must be    clear. 
Things we said    we'd do, and how I think they'll provide value: 
0) Be more open as    an organization:  That's important for Eclipse, and for people to know    they can get involved, but I think is only interesting with respect to    perceptions of the past which hopefully we're changing (hence #0).    
1)    Make it easier to write applications, make it easier to maintain applications:     This is a big win for anybody choosing Eclipse as an application    platform.  In fact, arguably that's the whole point of an application    platform, that you have to write less stuff because of all the hardened    libraries at your disposal.  Modelled UI, declarative UI all come into    play here. 
2) Make it easier    to contribute to the platform: based on the notion that by cleaning up the    code base and picking known popular technologies like EMF, people can step in    to contribute where they could not before.  Maybe more of an    organizational item, but also a benefit to consumers in the sense that they    believe that if they find a platform bug they can fix it, and if they find    missing features they can add them. 
3) Enable new kinds    of UIs:  This touches on both the "shape" of the application, so RCP on    steriods through modelled UI (which, by the way, I think we should start    calling "Flexible UI", because the model aspect is a technical choice only and    does not on its own ascribe goodness) [sorry Ed! :>].  It also touches    on the CSS work in making it easier to create new looks for your applications.     Presumably this has appeal to application developers because they can    modernize their apps, they are less restricted in look, they have more    opportunity for product branding, etc. 
4) Something about    flexible resources.... sorry haven't been keeping up here <sheepish    look>. 
5) Extending the    reach of the platform: web to desktop, desktop to web.  Reuse through    deployment in the web or the desktop.  This is where the _javascript_    integration, plugins in _javascript_, better support for web widgets in the    desktop all come in.  The carrot here is reduced development cost through    reuse, and parity of application look and feel for applications with both a    web and desktop component (increasingly popular). 
I'm sure I've    missed some stuff. 
Kevin    
      
Yes, what I wrote was weak in that respect.     Take 2.  <smack/>
Beyond the Enterprise, into    the Cloud
Tomorrow's applications will require integration of    hand-held devices, desktops, enterprise server applications, and applications    that are hosted "in the cloud" and are accessible from anywhere.  E4    makes Eclipse the best platform for delivering integrated applications that    scale into all of these environments.  With E4, you can now target tiny    devices, all the way up to cloud services like Amazon's EC2, all from a single    code base.
Take Eclipse's Architecture to the Next    Level
In order to accomplish the above objective, Eclipse will    fully adopt technologies--such as Eclipse RAP--that have been in incubation    for some time, and evolve its core workbench architecture so that it can fully    participate in distributed and web 2.0-enabled    applications.
Better?
Regards,
Dave
2009/1/27    Boris Bokowski <Boris_Bokowski@xxxxxxxxxx>    
What I meant was a position statement as defined by: http://www.ericsink.com/Positioning.html (and    probably many other marketing text books...)
"The basic idea of positioning is    that your product occupies a place in the mind of the people in your target    market.  You are defined by their perceptions of you. ... ask in which market segment you want    to be known as number one.  You want to be known as the best of your    breed, even if you need several qualifiers to constrain the scope of your    claim.  Don't think about being fifth place in a large market.     Instead, be number one in a smaller market. ... Identify the three parts of a    position:  superlative (why choose this product), label (what is this    product), and qualifiers (who should choose this product)."
I.e.    something like: "Equinox is the number one componentization solution for Java    applications in the embedded, desktop, and server context." or "RCP is the    best platform for rich client applications that need native L&F across all    major desktop OSs" or "The Eclipse IDE is the most popular IDE for Java    programmers".
Except we need something about e4...    ;-)
Boris
Dave Orme    wrote on 01/27/2009 04:36:12 PM: 
   
> OK, cool.     How about:
> 
> E4 will emphasize two    primary themes:
> 
> 1) Beyond the Enterprise,    into the Cloud
> 
> Eclipse has its roots as an    enterprise software framework, capably 
> delivering software    from embedded devices through the server.
> 
>    E4 will extend Eclipse with the capabilities needed to deliver    
> applications that live in the network cloud, whether on    services 
> like EC2 or on your own cluster.
>    
> 2) Take Eclipse's Architecture to the Next    Level
> 
> In order to accomplish the above    objective, Eclipse will fully adopt
> technologies--such as    Eclipse RAP--that have been in incubation for 
> some time, and    evolve its core workbench architecture so that it can
> fully    participate in distributed and web 2.0-enabled applications.
>    
> 
> Thoughts?
>    
> 
> Regards,
>    
> Dave 
   
> 2009/1/27 Boris Bokowski    <Boris_Bokowski@xxxxxxxxxx>
> Hi Dave,
>    
> I agree with you that it is very important to think about e4    from a 
> marketing point of view. Especially since we have    explored a good 
> number of areas and should be thinking about    what we want to deliver
> (both short term and long    term).
> 
> It's kind of funny that you are    mentioning marketing now. Just 
> yesterday, I came across a    blog posting about "marketing for geeks" 
> which I found    interesting as someone who had a small software 
> company in    the past. After enjoying all the parallels with what I 
>    experienced a couple of years ago, it occurred to me that many of    
> the issues apply to the e4 project as well, in particular    this one: 
> http://www.ericsink.com/Positioning.html    
> 
>    Ideally, we'd come up with a position statement about e4, maybe    
> something like your (1) below but shorter. Any    suggestions?
> 
> About (2), I don't think the    phrase "architecture clean-up" is 
> something you can use for    marketing purposes. :-P It's not about the
> intrinsic    properties, it's about what you can do with it.
>    
> Boris
> 
> 
>    Dave Orme wrote on 01/27/2009 03:22:56 PM:
> 
>    
> > Awhile back we put together a few paragraphs describing    what E4 is 
> > about from a (dirty) marketing point of    view.  Beware: if you read 
> > onward, you might need    to take a bath. ;-)
> > 
> > Seriously    though, what occurred to me last night is that E4 is 
> >    really about two themes:
> > 
> > 1)    Eclipse has always been about providing great infrastructure.     
> > SWT gives us great infrastructure horizontally    across operating 
> > system platforms.  eSWT, eRCP,    however, broaden Eclipse vertically 
> > down into the    embedded space.  E4 is about moving Eclipse up in the 
>    > vertical space so that it can also be a platform for cloud-based    
> applications.
> > After E4, we will cover    all major desktop and server operating 
> > systems    horizontally and the embedded through cloud space 
> >    vertically.  The enabling technologies here are Equinox, RAP, and    
> > [[the second E4 theme]] which is:
> >    
> > 2) Code and architecture clean-up.  Singletons are    (nearly) always 
> > evil, but especially so in a multi-user    environment like RAP.  
> > Resources can be anywhere.     Declarative UIs are nice.  Etc...  I 
> >    won't re-hash any more of this here as we're all well-versed in it by    now.
> > 
> > My    Question:
> > 
> > Does this sound like a    good way to describe and position E4?
> > 
>    > OK, maybe that's a silly question to ask a bunch of engineers.    ;-)
> > 
> > But does anyone think I'm    missing anything important or glossing 
> > over something    that I shouldn't be.
> > 
> >    
> > Regards,
> > 
> >    Dave Orme
> >_______________________________________________
> > e4-dev    mailing list
> > e4-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/e4-dev
> 
>_______________________________________________
> e4-dev    mailing list
> e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/e4-dev
>_______________________________________________
> e4-dev    mailing list
> e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/e4-dev    
_______________________________________________
e4-dev mailing    list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________
e4-dev mailing    list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev