[News.eclipse.foundation] Re: E4 / SWT 4.0

[Kevin McGuire <eclipse@xxxxxxxxxxxxxxxxxxxxx>]

Just wanted to jump in and echo what Tom said (eloquently, as usual).

A driving factor for e4 is to make it easier to contribute. One of the 
huge barriers to entry right now is the code itself.  Its complex, its 
brittle, its obscure.  Sometimes its more about the particular person 
who wrote it, who has since moved on.  Sometimes we're afraid to change 
things because we're no longer sure how the code works anymore.

Because of this, each change is more costly that it should be.  That 
unfortunately sets the bar quite high for contribution.  Clearly that 
needs to be fixed.  And its not going to be fixed solely through better 
documentation because the problems are fundamental in the code.

I guess I'd like to believe that the barrier to contribution is mostly 
technical, some communication.  Some of the discussion in this thread 
has implied that its about personalities.  Maybe I'm naive but I'd like 
to think its not that, that maybe that's just how it comes out on the 
surface.  Well ok on a practical note, technology is a lot easier to fix 
than personalities!

The thing is, we *all* want to make it easier to contribute.  We want to 
make it easier for others, because that's goodness for the community and 
it makes Eclipse stronger.  We want to do it for ourselves, because then 
we can get more work done.

I can only speak for myself, but being a fulltime committer can be a 
pretty frustrating experience.  I always feel so stupid, there's too 
much to know!  I can imagine that magnified many fold for the casual 
contributor.

So what to do about it?

We've decided that the cost benefit of trying to move the current code 
base forward is no longer equitable. As caretakers of Eclipse, we 
believe this is the thing we need to do to keep it healthy.  As always 
with these kinds of investments, it comes at the cost of immediate 
improvement, with the hope of long term benefit.

By way of analogy, recently my city (Ottawa) has been going through huge 
capital investement in replacing 100+ year old water and sewer lines. 
(Aside: I especially like this analogy since we consider the platform 
"plumbing" :> ).  Of course lots of people say, "Things work fine, I 
turn on my tap and water comes out, why are we spending all this money? 
 Why isn't the money being spent on <insert favorite cause>?".  You see 
no immediate benefit. But those whose job it is to care for such things 
believe that the moment has come for that capital expenditure, so that 
things will continue to work smoothly into the future and so the city 
can grow.

And I trust to that. Because as we all know, you sure have a mess on 
your hands when one of those suckers breaks!


Tom Schindl wrote:
> [...]
>
> > > There are lots of examples like this in the computing world. Do you 
> > > think Apple would still exist if they had continued to fix each and 
> > > every bug in Mac OS 9 rather than making a cut and moving everybody 
> > > over to Mac OS X with a solid BSD base? Don't they screw everybody 
> > > over again by discontinuing Carbon and making Cocoa development a 
> > > requirement? I am sure they haven't fixed all the bugs in Carbon 
> > > before they moved their developers over to Cocoa.
> >
> > The Apple examples are excellent ones, and I understand the point 
> > behind them. In terms of the M$ comparison, I was referring to Office, 
> > XP and Vista where we keep getting more and more eye candy and other 
> > features we don't need while numerous bugs and major usability 
> > problems are left unaddressed. Office, especially, has major problems 
> > with that.
> > Anyway, your point is understood; but it does not trump everything, 
> > and my point about conflicting messages ("we need more people to help" 
> > vs. "let's dedicate significant time and effort to e4") is also still 
> > valid, I think.
>
> IMHO the current codebase makes it so hard to add a new feature (e.g. 
> talk to Eric and ask him how long it took him to implement a small 
> feature into the presentation layer) that a cut is needed. Eclipse 
> *needs* a solid base to stay the number 1 platform for the foreseeable 
> future.
>
> Some of the features requested can't get implemented because they have 
> such a deep impact on the whole platform that you can't do them 
> individually or if you do that the platform internally needs compatility 
> layers and slows done because of this.
>
> If you take a look how many troubles P2 had in the last months you can 
> estimate how many troubles you'll get when you e.g. change the 
> resource-management.
>
> > > The reason we are working on e4 as well as (not instead of!) the 3.x 
> > > stream is that we believe that Eclipse as a component integration 
> > > platform will not exist five or ten years from now unless we 
> > > re-invent it in a way that makes Eclipse relevant to programmers 
> > > using other programming languages, developers working on distributed 
> > > applications, and users who would like to see (parts of) the 
> > > functionality they use in an Eclipse-based desktop application in a 
> > > browser. We will not achieve all of these goals within the next few 
> > > months, but I think they work well as a vision for what we are aiming 
> > > at.
> >
> > While I agree with some of those assertions, I don't agree with them 
> > all (and for most of them, my degree of confidence is relatively low). 
> > For example, I don't agree that every software technology needs to 
> > have a browser-based strategy. I'm not alone in predicting that the 
> > current level of hype and mania may not sustain.
> > My broader point, regardless of the detailed ideas and decisions 
> > constituting the vision, is this: who is setting this vision and how 
> > can the community have more influence into it (in a meaningful way, 
> > not just as a token: "Yes, thanks for your opinion")? I find things to 
> > be too opaque and difficult to enter for the community in general and 
> > am trying to use this thread to raise awareness of that to the 
> > committers and project leaders.
> > BTW, I really do appreciate the participation in this thread that 
> > we're getting - it is a good sign, I think. I encourage more community 
> > members AND project committers to chime in so it's not just the 
> > loudmouths like me being heard ;-)
>
> If you look at the discussion on the e4 mailing list one notices that 
> the browser stuff is only *one* point of the big picture (CSS doesn't 
> count). It's right that the browser point has some influence on other 
> topics (e.g. multiple workspaces in one OSGi) but this will also help 
> Desktop-Eclipse.
>
> In my radical way of thinking I even started to split out SWT specific 
> view in my prototype and make it replaceable with anything you want 
> (e.g. an GEF based implementation).
>
> It's right that some of the resources available are shifted to e4 but 
> not doing this we are stuck in a few years from now. As Boris points out 
> bugfixing in 3.x as well as introducing new features (not as radical new 
> ones as you'll get in e4). I could even think that new features added to 
> e4 can get back ported to 3.x.
>
> IMHO currently is the right time for e4. There are the people around who 
> know what they did wrong in 3.x and how they can improve it in e4.
>
> Tom