Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Orion/Project mission statement"

m (fix typo)
 
(One intermediate revision by one other user not shown)
Line 12: Line 12:
  
 
A majority of them will say they use:
 
A majority of them will say they use:
# a text editor (TextMate, FTW!)
+
# A text editor (TextMate, FTW!)
 
# FireBug (and increasingly Web Inspector)
 
# FireBug (and increasingly Web Inspector)
# some kind of (usually command line based) VCM system, although that isn't nearly as universal.
+
# Some kind of (usually command line based) VCM system, although that isn't nearly as universal.
  
 
The remainder -- typically those who are enterprise developers -- will say they use some commercial, desktop-based IDE. The benefit of this kind of tool is that in one place you can get end-to-end support for a wide range of the tasks required for maintaining a site's client code, business logic, and server infrastructure. The issue with this kind of tooling is that it tends to grow to the point where it can no longer be agile enough to respond as the (ferociously active) web world changes.  
 
The remainder -- typically those who are enterprise developers -- will say they use some commercial, desktop-based IDE. The benefit of this kind of tool is that in one place you can get end-to-end support for a wide range of the tasks required for maintaining a site's client code, business logic, and server infrastructure. The issue with this kind of tooling is that it tends to grow to the point where it can no longer be agile enough to respond as the (ferociously active) web world changes.  
  
Whichever group you talk to, you will hear that, the state of today's web tooling is such that developers sometimes feel they must to turn to proprietary technologies like Adobe's Flash simply because the tools to support it actually work well.  
+
Whichever group you talk to, you will hear that the state of today's web tooling is such that developers sometimes feel they must turn to proprietary technologies like Adobe's Flash simply because the tools to support it actually work well.
  
 
== The challenge ==
 
== The challenge ==
Line 25: Line 25:
  
 
The strengths of the web that have allowed it grow at its phenomenal rate include:
 
The strengths of the web that have allowed it grow at its phenomenal rate include:
# highly distributed content
+
# Highly distributed content
# scalable computing power
+
# Scalable computing power
# simple connectivity -- links
+
# Simple connectivity -- links
# trivial update mechanism (i.e. refresh the page)
+
# Trivial update mechanism (i.e. refresh the page)
# powerful rendering engine -- browsers
+
# Powerful rendering engine -- browsers
# very large and active community
+
# Very large and active community
  
 
To understand the solution to the problem you need only to recognize that the tools must be built on these strengths, not just support them:
 
To understand the solution to the problem you need only to recognize that the tools must be built on these strengths, not just support them:
# individual components, as well as the artifacts they manipulate, will come from all over the web
+
# Individual components, as well as the artifacts they manipulate, will come from all over the web
# elastic computing -- the "cloud" -- will allow large-scale analysis and manipulation of artifacts beyond what is possible on the desktop
+
# Elastic computing -- the "cloud" -- will allow large-scale analysis and manipulation of artifacts beyond what is possible on the desktop
# there need be no central "IDE" or central artifact repository; components and artifacts will live where they are useful and be linked together through industry standard interfaces to support developer work-flows
+
# There need be no central "IDE" or central artifact repository; components and artifacts will live where they are useful and be linked together through industry standard interfaces to support developer work-flows
# refreshing a web page will be all that it takes to be running the most current code
+
# Refreshing a web page will be all that it takes to be running the most current code
# look and feel will be highly configurable and tweak-able using standard web technology
+
# Look and feel will be highly configurable and tweak-able using standard web technology
# *any* web based tool, built by anyone in the web community, should be usable as part of the development process
+
# ''Any'' web based tool, built by anyone in the web community, should be usable as part of the development process
  
 
In short, '''we will move software development to the web as a web experience, not by cloning the desktop IDE experience.'''
 
In short, '''we will move software development to the web as a web experience, not by cloning the desktop IDE experience.'''

Latest revision as of 09:57, 3 November 2011

Tooling platforms

The Eclipse Project started, more than ten years ago, with a core group of developers who wanted to create a new way to build software development tools. The vision then, was to create a generalized platform on the desktop with a well defined extensibility story that made it easy to "plug in" new capabilities. The first example of this was the Java development tools that were built out of necessity to support the creation of the platform itself, which was in turn being written in Java. The tight feedback loop that resulted -- which the developers took to calling "eating your own dog food" -- allowed for very rapid advancement of the platform.

As a result, within a brief time "Eclipse" grew beyond being a tooling platform. Today it is used to create a whole range of rich, cross-platform client applications, and the Eclipse Runtime is widely used on both the client and server sides. Throughout this time though, the Eclipse Project developers never lost sight of their roots as tool providers; the Eclipse Platform continues to be the best basis for building cross-platform, desktop tools.

Although the development of Eclipse has been rapid, during effectively the same period another "platform" has far outstripped it, going from being a little more than a way to access remote content to something that may, in fact, be the true successor of the desktop. That platform is, of course, the World Wide Web. The rate of development of the web is such that today many sites are delivering "applications" as powerful as their desktop equivalents, albeit with different strengths and weaknesses.

The state of tools for the open web

Looking at the tooling side of the web-as-an-application-platform however, the picture is not nearly as rosy. If you ask web developers what kinds of tools they actually use on a daily basis, you will find there are typically two camps.

A majority of them will say they use:

  1. A text editor (TextMate, FTW!)
  2. FireBug (and increasingly Web Inspector)
  3. Some kind of (usually command line based) VCM system, although that isn't nearly as universal.

The remainder -- typically those who are enterprise developers -- will say they use some commercial, desktop-based IDE. The benefit of this kind of tool is that in one place you can get end-to-end support for a wide range of the tasks required for maintaining a site's client code, business logic, and server infrastructure. The issue with this kind of tooling is that it tends to grow to the point where it can no longer be agile enough to respond as the (ferociously active) web world changes.

Whichever group you talk to, you will hear that the state of today's web tooling is such that developers sometimes feel they must turn to proprietary technologies like Adobe's Flash simply because the tools to support it actually work well.

The challenge

This then is the crux of the problem: How can we create tools for open web development that are both powerful enough and elastic enough to support the full scope of the web as it continues to advance and grow?

The strengths of the web that have allowed it grow at its phenomenal rate include:

  1. Highly distributed content
  2. Scalable computing power
  3. Simple connectivity -- links
  4. Trivial update mechanism (i.e. refresh the page)
  5. Powerful rendering engine -- browsers
  6. Very large and active community

To understand the solution to the problem you need only to recognize that the tools must be built on these strengths, not just support them:

  1. Individual components, as well as the artifacts they manipulate, will come from all over the web
  2. Elastic computing -- the "cloud" -- will allow large-scale analysis and manipulation of artifacts beyond what is possible on the desktop
  3. There need be no central "IDE" or central artifact repository; components and artifacts will live where they are useful and be linked together through industry standard interfaces to support developer work-flows
  4. Refreshing a web page will be all that it takes to be running the most current code
  5. Look and feel will be highly configurable and tweak-able using standard web technology
  6. Any web based tool, built by anyone in the web community, should be usable as part of the development process

In short, we will move software development to the web as a web experience, not by cloning the desktop IDE experience.

The key to all this is in finding ways to integrate tools that have been built (and will be built in the future) into coherent workflows that solve real world web developer problems. This is not about requiring a particular toolkit to implement user interfaces. Nor is it about building development middleware like source code and change management systems. The challenge rather is interfacing with those kinds of systems and in general providing access to development artifacts in an open, standard way. For example, the good work that is happening around open specifications for resources and interfaces at OSLC. We will participate wherever work is happening that advances the state of tools for the open web, and we will "fill in the holes" wherever needed. Overall, we will drive development on the web until it is as popular as the web itself. That is Orion's mission.

Back to the top