Hi Kevin, Thanks for your detailed reply.
I think there are two categories of marketing messages we want to communicate: 1) Eclipse *is* the future. Therefore, Eclipse is the safe choice for you. 2) Detailed selling points that will give specific individuals and companies reasons to adopt, participate, and contribute. What I was writing before was targeted at #1. I think we do a pretty good job communicating #2 already, not that there isn't room to be more explicit, intentional, frequent, and so on. But to communicate about #1--being the future--one has to identify trends that are likely to safely predict where the field is headed. And if we serve those trends well and communicate this effectively, then we can ride the wave of that trend to its logical conclusion. In this context, I probably should talk a bit about what I think about when I talk about "cloud computing". I have an Android-based phone. It is the first thing I've seen that is more useful to me than a PalmOS device for actually organizing my life. There are two ways of looking at the reasons why: a user's point of view and a technical architecture point of view. - The user's view: >From a user's point of view, there is almost no difference between using GMail on the phone and using the web app. They're both fast, and they are automatically in sync with each other. The same is true of the calendar application and Google Calendar. From a user's point of view, the whole notion of "syncing my PDA" just disappears. The data is just there where and when I need it. - The architect's view: The data actually lives both on the phone and in the cloud--on Google's servers. The two are automatically synced periodically (often enough that they are rarely out of sync). So there's actually a rich graphical application running on the phone. It's synced using the phone's internet connection with the corresponding Google application. In an enterprise environment, it would also be synchronized with Notes, Outlook, etc. So email on the phone is actually a suite of 2-3 applications (mobile, web, desktop) that all automatically stay in sync with each other. They all feel like they are really one application and it's impossible to say (from a user's point of view) where the data actually is stored. But the mail client and the calendar integrate too. The integration appears to happen both in the web app and on the phone, but from the user's perspective it's all seamless since everything is synchronzed. From the user's point of view, their data is just always available, whenever and wherever they need it. So from the user's point of view, again, the data lives in "the cloud", as-in the network cloud. And local replication and queuing is used to give the illusion of being online all the time, even if there happens to be no signal at a given moment. If I wanted to deliver a service myself that does this, there's a whole lot of pieces to the puzzle. But it's really hard to go wrong choosing Eclipse RCP, because at a minimum, you can build both a desktop and a Web 2.0 version of the same application from the same code base (not 100% reuse, but close). And shortly, ERCP will let you build the mobile version for some phones too with a very high level of reuse. And today, you can also reuse a lot of the core functionality and do an Android UI with a really significant amount of code reuse. So one code base can deliver nearly all aspects of a cloud-based architecture if it's built on Eclipse. Conclusion The trend is for data to be available anywhere, all the time. "Cloud computing" is the catch phrase that to me really signifies a very specific style of (often mobile) distributed computing architecture that enables this kind of integrated application suite. The fact that it might be hosted on Amazon EC2 or some other service is merely a cooincidence of the economies of scale that make it cheaper for me to pay someone else to run the data center, keep the backups, provision servers, and so on than to do it myself. In the media, "cloud computing" sometimes refers to the hardware infrastructure that enables "cloud computing" applications. But at Eclipse, we're all about the applications, so that's the sense in which I'm talking about "cloud computing". We serve everything from the mobile space all the way through desktops and servers, now to Web 2.0 applications. We have all the pieces needed to build a successful "cloud computing" application suite. In my view, this sort of evolution is just a logical next step for the computer industry. And in my view, Eclipse is ideally positioned to lead this charge. In fact, we're already developing and integrating all of the right technologies to do so under the E4 banner. Cloud computing is trendy. Jumping on a trend for trend's sake is probably self-defeating. But I think that Eclipse can make a really good case that if we are not the only end-to-end stack serving every aspect of a cloud-based application, that we're the most mature and successful. I think we should ride this wave for all it's worth. Regards, Dave 2009/1/27 Kevin McGuire <[email protected]> > > 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 > > > > *David Orme <[email protected]>* > Sent by: [email protected] > > 01/27/2009 05:24 PM > Please respond to > E4 Project developer mailing list <[email protected]> > > To > E4 Project developer mailing list <[email protected]> cc > Subject > Re: [e4-dev] What *are* we doing here??? <g> > > > > > 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 > <*[email protected]*<[email protected]> > > > What I meant was a position statement as defined by: * > http://www.ericsink.com/Positioning.html*<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 > > <*[email protected]*<[email protected]> > > > > 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*<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 > > > *[email protected]* <[email protected]> > > > *https://dev.eclipse.org/mailman/listinfo/e4-dev*<https://dev.eclipse.org/mailman/listinfo/e4-dev> > > > > _______________________________________________ > > e4-dev mailing list > > *[email protected]* <[email protected]> > > *https://dev.eclipse.org/mailman/listinfo/e4-dev*<https://dev.eclipse.org/mailman/listinfo/e4-dev> > > > _______________________________________________ > > e4-dev mailing list > > *[email protected]* <[email protected]> > > *https://dev.eclipse.org/mailman/listinfo/e4-dev*<https://dev.eclipse.org/mailman/listinfo/e4-dev> > > _______________________________________________ > e4-dev mailing list* > **[email protected]* <[email protected]>* > **https://dev.eclipse.org/mailman/listinfo/e4-dev*<https://dev.eclipse.org/mailman/listinfo/e4-dev> > > _______________________________________________ > e4-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/e4-dev > > > _______________________________________________ > e4-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/e4-dev > >
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
