Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » General (non-technical) » Eclipse Foundation » Re: E4 / SWT 4.0
Re: E4 / SWT 4.0 [message #54276] Mon, 02 June 2008 09:27 Go to next message
Eclipse User
Originally posted by: eclipse-news.rizzoweb.com

Note: I've copied this thread over to eclipse.foundation because I think
it has broader scope than just SWT.
(my own comments below)

Ed Merks wrote:
>> 2) the vision for the next releases
> There will still be 3.x releases. The plans for those aren't out
> yet. Without community involvement, those plans will most likely be
> driven by the priorities of choice for the people making the plans.

There's been a lot I've wanted to comment on in this thread, but this
above is the crux of the problem: as a community member (as opposed to a
committer), it is practically impossible to be "involved" in the
planning beyond just entering, commenting on, and voting for Bugilla
reports. That is the only tool we really have, and yet (as Laurent has
pointed out and others have surely noticed) many, many issues in
Bugzilla are either rejected from the outset (some with, and some
without, cause) or simply wither on the vine from lack of attention.
This includes both bugs and enhancements. Ed, your particular example of
EMF defects, while admirable, is not the standard across the other
top-level projects; EMF is an anomaly, in my experience, in this area.

So, if our only tool to be involved in planning is a victim of the
priorities of those doing the planning, how are we to "get involved" in
the planning when our priorities differ from the decision makers.
The barrier to entry is indeed way to high and, again as Laurent has
been saying, most of us do not work for a company that is willing to pay
us to put in the amount of time it actually takes to get respected
status and hold the ear of the project teams. Volunteer time for someone
who spends his working hours neck-high in Eclipse is *significantly*
easier than for someone who only uses Eclipse projects most of the time
and want to try to contribute in his spare time. I think that fact is
often overlooked by the existing contributors. The barrier to entry and
learning curves are very, very high; those of you whose employment has
paid that cost have a big advantage over those who have to shoulder it
on their own.

Eclipse committers can say all they want that it is possible for an
outsider to join the team with enough contribution, but that is like
saying it is possible for "anyone" to become president (or prime
minister) - yes, its technically possible but it is not practical.
Again, the barrier to entry is just so high. Now, before someone throws
a straw man into the discussion, let me be clear that of course I am not
advocating opening the doors and letting anyone and everyone commit
code. But for the comitter to repeatedly say "get involved" in response
to interrogation or critic, well that just trivializes what that really
takes to get involved beyond just contributing ideas and bug reports. To
be honest, it is a little insulting to those of us who *do* contribute a
lot that is not in the form of code. Trust me, I've experienced the
glass wall many times, despite my prominent position in the community.
The bottom line: there is a bit of a perceived glass wall between the
community and the project teams, and until that is recognized by the
teams (instead of denying or defending it without reflecting upon it)
there will continue to be this "us and them" mentality from this side of
that wall.
Look, I don't think anyone here is being malicious or ungrateful or
anything like that - I think we are just trying to be honest.
Most of us in the community greatly respect the work that the Eclipse
project teams do and greatly appreciate the products that they produce.
But there *are* problems in the system and if we can't have open, honest
discussion about them, we might as well all go somewhere else because
without that openness and honesty, Eclipse will be doomed to failure.

Eric
Re: E4 / SWT 4.0 [message #54303 is a reply to message #54276] Mon, 02 June 2008 10:14 Go to previous messageGo to next message
Eclipse User
Originally posted by: merks.ca.ibm.com

Eric,

Oh no. You've escalated to the powers that be. :-P I'll remind
everyone that the opinions I express are my own, no one else's...

Eric Rizzo wrote:
> Note: I've copied this thread over to eclipse.foundation because I
> think it has broader scope than just SWT.
> (my own comments below)
>
> Ed Merks wrote:
>>> 2) the vision for the next releases
>> There will still be 3.x releases. The plans for those aren't out
>> yet. Without community involvement, those plans will most likely be
>> driven by the priorities of choice for the people making the plans.
>
> There's been a lot I've wanted to comment on in this thread,
But I didn't leave you a word edgewise. Hehehe.
> but this above is the crux of the problem: as a community member (as
> opposed to a committer), it is practically impossible to be "involved"
> in the planning beyond just entering, commenting on, and voting for
> Bugilla reports.
Yes, the plans seem to come out of the mountains like stone tablets.
> That is the only tool we really have, and yet (as Laurent has pointed
> out and others have surely noticed) many, many issues in Bugzilla are
> either rejected from the outset (some with, and some without, cause)
> or simply wither on the vine from lack of attention.
I know it's frustrating when issues aren't addressed. I recently went
on a little spat of trying to fix a JDT bug and some PDE bugs. I know
pretty much nothing about that code, but I didn't let it stop me. My
JDT bug fix turned out to be not so good, but the commiters helped turn
it into a good fix. My PDE efforts were a little more successful. I
know it's tough to wade through other people's code, but I'm a firm
believer in "where there's a will there's a way"...
> This includes both bugs and enhancements. Ed, your particular example
> of EMF defects, while admirable, is not the standard across the other
> top-level projects; EMF is an anomaly, in my experience, in this area.
Oh sure, now my project is an anomaly. What insults will I have to
endure next. :-P Another principle I believe in strongly is do as you
would have others do, kind of like the golden rule. Lead by example.
Maybe folks will copy. Maybe not, but it makes me feel good anyway.
Gosh but it's a high horse I'm on. It's a long way to the ground from
up here!
>
> So, if our only tool to be involved in planning is a victim of the
> priorities of those doing the planning, how are we to "get involved"
> in the planning when our priorities differ from the decision makers.
Even the board has issues with this kind of thing. I know folks don't
like to hear it, but everyone needs to be reminded that if you don't
fund the resource, you don't get the control. So, however difficult it
may be, the most effective tool is to get involved and do it yourself.
We all know the welfare state doesn't work, so the idea of getting
together and making a wish list for others to fulfill just isn't a
workable solution.
> The barrier to entry is indeed way to high and, again as Laurent has
> been saying, most of us do not work for a company that is willing to
> pay us to put in the amount of time it actually takes to get respected
> status and hold the ear of the project teams.
And there in lies one of the main problems. Yet no one seems all that
compelled to work hard of fixing this particular problem. Clearly if
everyone takes this attitude, we'd not have an open source project...
> Volunteer time for someone who spends his working hours neck-high in
> Eclipse is *significantly* easier than for someone who only uses
> Eclipse projects most of the time and want to try to contribute in his
> spare time.
Yep, I have an advantage of having been in this swamp for many years. I
know where the alligators lurk...
> I think that fact is often overlooked by the existing contributors.
No, but when there's a barrier, you can't just stand back forever and
hope it will come down...
> The barrier to entry and learning curves are very, very high; those of
> you whose employment has paid that cost have a big advantage over
> those who have to shoulder it on their own.
Indeed, I feel especially fortunate! So I try to run things in an
anomalous way to share that...
>
> Eclipse committers can say all they want that it is possible for an
> outsider to join the team with enough contribution, but that is like
> saying it is possible for "anyone" to become president (or prime
> minister) - yes, its technically possible but it is not practical.
I don't buy that argument. Why in Canada, they let pretty much anyone
be prime minister! :-P Our dollar is even in pretty good shape because
some of our choices have been good ones.
> Again, the barrier to entry is just so high.
Is it artificially high or is it high in a way that can be lowered? Is
this barrier actually higher than the barrier that says, I don't want to
spend money on open source work because I only have so much and want to
use it on product development....
> Now, before someone throws a straw man into the discussion,
I would never do that. :-P
> let me be clear that of course I am not advocating opening the doors
> and letting anyone and everyone commit code.
The committers won't stand for that! After all, who's on the hook to
support what's committed.
> But for the comitter to repeatedly say "get involved" in response to
> interrogation or critic, well that just trivializes what that really
> takes to get involved beyond just contributing ideas and bug reports.
I think there is a lot of trivialization on both sides of the fence.
One could trivialization seems to deserve another...
> To be honest, it is a little insulting to those of us who *do*
> contribute a lot that is not in the form of code.
As I pointed out in the thread, even constructive feedback and early
testing is a contribution. So is documentation, or answering copious
volumes of newsgroup questions, as in your case.
> Trust me, I've experienced the glass wall many times, despite my
> prominent position in the community.
That's a mirror. Hehehehe.
> The bottom line: there is a bit of a perceived glass wall between the
> community and the project teams, and until that is recognized by the
> teams (instead of denying or defending it without reflecting upon it)
> there will continue to be this "us and them" mentality from this side
> of that wall.
I think many teams could work on their openness. I'm sure I don't do it
perfectly myself.
> Look, I don't think anyone here is being malicious or ungrateful or
> anything like that - I think we are just trying to be honest.
I've certainly tried to do the same!
> Most of us in the community greatly respect the work that the Eclipse
> project teams do and greatly appreciate the products that they
> produce. But there *are* problems in the system and if we can't have
> open, honest discussion about them, we might as well all go somewhere
> else because without that openness and honesty, Eclipse will be doomed
> to failure.
Just be aware that there are problems on both sides of the fence, so
when there are open and honest discussions, we need to be sure that this
notion that Eclipse should service wish lists for free will also need
close inspection.

Constructive criticism from true contributors such as yourself certainly
has more weight than it would coming from others who show up only with
wish lists...
>
> Eric
Re: E4 / SWT 4.0 [message #54329 is a reply to message #54276] Mon, 02 June 2008 19:07 Go to previous messageGo to next message
Francis Upton IV is currently offline Francis Upton IV
Messages: 472
Registered: July 2009
Location: Oakland, CA
Senior Member
Hi Eric,

I'm just jumping in here, not really knowing the context of this, but I
want to make a couple of comments to what you say:

1) The main problem is there are not enough people working on the code
to get things done. Much of the work is done by the committers, but
also quite a bit is contributed. But the sum total of that is far less
than what we need to clean out the bug backlog and satisfy all of the
requests of the community.

*We need more people doing the work*; it really does not matter if they
are committers or if they are contributors.

I think however we need to get a *lot* better at encouraging
contributions and contributors. We need more wiki pages and help and
communication to help people contribute. We need infrastructure for
this so that all projects can have a lot of materials and support to
make it easy to document how to contribute, find contributors, recognize
contributions and contributors, and do a better job of identifying
work where we need help. Right now it's very uneven between projects
because there is little in the way of common support for encouraging
contributions.

2) I also think, like any other open source (or many internal
companies), it's largely a matter of relationships. You can get what
you want by contributing code certainly; and you can also get what you
want by working with committers and other contributors and having them
make things a priority. If you are interested in a particular area,
then get to know the developers and that's how you will influence
things. I'm not saying this is right, it's just how things seem to work
(at least in some areas).

The problem here is this is entirely a volunteer effort, and yes there
are full time committers, but their company is effectively volunteering
their time. Personally, I don't want to see any more elaborate
mechanisms for prioritizing things or having product mangement, etc
because that will just add more process overhead.

Eric Rizzo wrote:
> Note: I've copied this thread over to eclipse.foundation because I think
> it has broader scope than just SWT.
> (my own comments below)
>
> Ed Merks wrote:
>>> 2) the vision for the next releases
>> There will still be 3.x releases. The plans for those aren't out
>> yet. Without community involvement, those plans will most likely be
>> driven by the priorities of choice for the people making the plans.
>
> There's been a lot I've wanted to comment on in this thread, but this
> above is the crux of the problem: as a community member (as opposed to a
> committer), it is practically impossible to be "involved" in the
> planning beyond just entering, commenting on, and voting for Bugilla
> reports. That is the only tool we really have, and yet (as Laurent has
> pointed out and others have surely noticed) many, many issues in
> Bugzilla are either rejected from the outset (some with, and some
> without, cause) or simply wither on the vine from lack of attention.
> This includes both bugs and enhancements. Ed, your particular example of
> EMF defects, while admirable, is not the standard across the other
> top-level projects; EMF is an anomaly, in my experience, in this area.
>
> So, if our only tool to be involved in planning is a victim of the
> priorities of those doing the planning, how are we to "get involved" in
> the planning when our priorities differ from the decision makers.
> The barrier to entry is indeed way to high and, again as Laurent has
> been saying, most of us do not work for a company that is willing to pay
> us to put in the amount of time it actually takes to get respected
> status and hold the ear of the project teams. Volunteer time for someone
> who spends his working hours neck-high in Eclipse is *significantly*
> easier than for someone who only uses Eclipse projects most of the time
> and want to try to contribute in his spare time. I think that fact is
> often overlooked by the existing contributors. The barrier to entry and
> learning curves are very, very high; those of you whose employment has
> paid that cost have a big advantage over those who have to shoulder it
> on their own.
>
> Eclipse committers can say all they want that it is possible for an
> outsider to join the team with enough contribution, but that is like
> saying it is possible for "anyone" to become president (or prime
> minister) - yes, its technically possible but it is not practical.
> Again, the barrier to entry is just so high. Now, before someone throws
> a straw man into the discussion, let me be clear that of course I am not
> advocating opening the doors and letting anyone and everyone commit
> code. But for the comitter to repeatedly say "get involved" in response
> to interrogation or critic, well that just trivializes what that really
> takes to get involved beyond just contributing ideas and bug reports. To
> be honest, it is a little insulting to those of us who *do* contribute a
> lot that is not in the form of code. Trust me, I've experienced the
> glass wall many times, despite my prominent position in the community.
> The bottom line: there is a bit of a perceived glass wall between the
> community and the project teams, and until that is recognized by the
> teams (instead of denying or defending it without reflecting upon it)
> there will continue to be this "us and them" mentality from this side of
> that wall.
> Look, I don't think anyone here is being malicious or ungrateful or
> anything like that - I think we are just trying to be honest.
> Most of us in the community greatly respect the work that the Eclipse
> project teams do and greatly appreciate the products that they produce.
> But there *are* problems in the system and if we can't have open, honest
> discussion about them, we might as well all go somewhere else because
> without that openness and honesty, Eclipse will be doomed to failure.
>
> Eric


Re: E4 / SWT 4.0 [message #54356 is a reply to message #54329] Mon, 02 June 2008 20:02 Go to previous messageGo to next message
Eclipse User
Originally posted by: merks.ca.ibm.com

Francis,

Comments below.

Francis Upton (News) wrote:
> Hi Eric,
>
> I'm just jumping in here, not really knowing the context of this, but
> I want to make a couple of comments to what you say:
>
> 1) The main problem is there are not enough people working on the code
> to get things done. Much of the work is done by the committers, but
> also quite a bit is contributed. But the sum total of that is far
> less than what we need to clean out the bug backlog and satisfy all of
> the requests of the community.
You've hit the nail on the head.
>
> *We need more people doing the work*; it really does not matter if
> they are committers or if they are contributors.
That right. Doers. We need lots of doers. Do anything, but do something.
>
> I think however we need to get a *lot* better at encouraging
> contributions and contributors.
Exactly. Projects ought to have project file sets and detailed
instructions of exactly how the committers set up their development
environments. It's the best way to encourage high quality contributions.
> We need more wiki pages and help and communication to help people
> contribute.
Bingo. And everyone can help with wiki pages. You can see the history
of http://wiki.eclipse.org/EMF/Getting_Source to see just how much the
community helped contribute toward this valuable information source.
> We need infrastructure for this so that all projects can have a lot of
> materials and support to make it easy to document how to contribute,
> find contributors, recognize contributions and contributors, and do a
> better job of identifying work where we need help.
I think this is exactly the barrier that Eric refers to. We as a
community need to eliminate the barriers one by one. The committers
need to take significant responsibility for getting the processing
moving in the right direction.
> Right now it's very uneven between projects because there is little
> in the way of common support for encouraging contributions.
It's totally hit in miss. Some projects I've tried to work on are
trivial to set up (RAP), while others remain a dark mystery. I won't
point fingers...
>
> 2) I also think, like any other open source (or many internal
> companies), it's largely a matter of relationships.
It's all about sociology. Make friends. Contribute. Flatter egos if
you need to. Just do it.
> You can get what you want by contributing code certainly; and you can
> also get what you want by working with committers and other
> contributors and having them make things a priority.
There are just some people I really like and when they want something,
their needs become my priority. That's human nature. Don't bemoan it.
Use it to your advantage. A very wise person once explained to me that
it's all about influence. So learn effective ways to influence others.
> If you are interested in a particular area, then get to know the
> developers and that's how you will influence things.
Totally excellent advice. I pay very close attention to the kinds of
issues that interest other people so that I can help carve out space in
EMFT for that interest to thrive. I love working with like minded
people. It makes my day brighter. Committers need to think about their
community and the community needs to think about the fact that generally
everyone will do things that are self serving. It's an issue of how
best to make self serving behavior turn into community serving behavior...
> I'm not saying this is right, it's just how things seem to work (at
> least in some areas).
Human nature is what it is. The saints are few and far between. Don't
expect to find a lot of them. If you've only got vinegar to dish out,
you'll find the party you host is a small one...
>
> The problem here is this is entirely a volunteer effort, and yes there
> are full time committers, but their company is effectively
> volunteering their time.
I've tried to make that point too. Just because IBM pays my bill
doesn't make what I do any less free. Return on investment is what
drives real economies, so folks ought not to expect open source to be
any different.
> Personally, I don't want to see any more elaborate mechanisms for
> prioritizing things or having product mangement, etc because that will
> just add more process overhead.
A wish list management process isn't going to cut it. I've made it
clear to more than enough people that if you don't fund the resource,
you don't control the resource. If you're willing to pool your resource
with the resource of others, you might will find you have influence over
far more resource than you could otherwise afford. If you're willing to
fund nothing, expect nothing, and you will not be disappointed when
that's all you get.

You give great advice. How did you get to be so smart anyway? :-P
>
> Eric Rizzo wrote:
>> Note: I've copied this thread over to eclipse.foundation because I
>> think it has broader scope than just SWT.
>> (my own comments below)
>>
>> Ed Merks wrote:
>>>> 2) the vision for the next releases
>>> There will still be 3.x releases. The plans for those aren't out
>>> yet. Without community involvement, those plans will most likely be
>>> driven by the priorities of choice for the people making the plans.
>>
>> There's been a lot I've wanted to comment on in this thread, but this
>> above is the crux of the problem: as a community member (as opposed
>> to a committer), it is practically impossible to be "involved" in the
>> planning beyond just entering, commenting on, and voting for Bugilla
>> reports. That is the only tool we really have, and yet (as Laurent
>> has pointed out and others have surely noticed) many, many issues in
>> Bugzilla are either rejected from the outset (some with, and some
>> without, cause) or simply wither on the vine from lack of attention.
>> This includes both bugs and enhancements. Ed, your particular example
>> of EMF defects, while admirable, is not the standard across the other
>> top-level projects; EMF is an anomaly, in my experience, in this area.
>>
>> So, if our only tool to be involved in planning is a victim of the
>> priorities of those doing the planning, how are we to "get involved"
>> in the planning when our priorities differ from the decision makers.
>> The barrier to entry is indeed way to high and, again as Laurent has
>> been saying, most of us do not work for a company that is willing to
>> pay us to put in the amount of time it actually takes to get
>> respected status and hold the ear of the project teams. Volunteer
>> time for someone who spends his working hours neck-high in Eclipse is
>> *significantly* easier than for someone who only uses Eclipse
>> projects most of the time and want to try to contribute in his spare
>> time. I think that fact is often overlooked by the existing
>> contributors. The barrier to entry and learning curves are very, very
>> high; those of you whose employment has paid that cost have a big
>> advantage over those who have to shoulder it on their own.
>>
>> Eclipse committers can say all they want that it is possible for an
>> outsider to join the team with enough contribution, but that is like
>> saying it is possible for "anyone" to become president (or prime
>> minister) - yes, its technically possible but it is not practical.
>> Again, the barrier to entry is just so high. Now, before someone
>> throws a straw man into the discussion, let me be clear that of
>> course I am not advocating opening the doors and letting anyone and
>> everyone commit code. But for the comitter to repeatedly say "get
>> involved" in response to interrogation or critic, well that just
>> trivializes what that really takes to get involved beyond just
>> contributing ideas and bug reports. To be honest, it is a little
>> insulting to those of us who *do* contribute a lot that is not in the
>> form of code. Trust me, I've experienced the glass wall many times,
>> despite my prominent position in the community. The bottom line:
>> there is a bit of a perceived glass wall between the community and
>> the project teams, and until that is recognized by the teams (instead
>> of denying or defending it without reflecting upon it) there will
>> continue to be this "us and them" mentality from this side of that wall.
>> Look, I don't think anyone here is being malicious or ungrateful or
>> anything like that - I think we are just trying to be honest.
>> Most of us in the community greatly respect the work that the Eclipse
>> project teams do and greatly appreciate the products that they
>> produce. But there *are* problems in the system and if we can't have
>> open, honest discussion about them, we might as well all go somewhere
>> else because without that openness and honesty, Eclipse will be
>> doomed to failure.
>>
>> Eric
Re: E4 / SWT 4.0 [message #54414 is a reply to message #54356] Wed, 04 June 2008 11:51 Go to previous messageGo to next message
Boris Bokowski is currently offline Boris Bokowski
Messages: 272
Registered: July 2009
Senior Member
"Ed Merks" <merks@ca.ibm.com> wrote in message
news:g221ip$520$1@build.eclipse.org...
> Francis,
>
> ...
>
> You give great advice. How did you get to be so smart anyway? :-P

Very recently, Francis was elected as a committer on the Platform UI
component. Could there be a correlation? ;-P

But honestly, things are changing. Looking at the list of active committers
for the Platform project, and more specifically Platform UI (JFace,
Workbench, IDE), there are six active committers who work for IBM and two
who don't work for IBM. With Francis joining our team, we will have six vs.
three, or 66% IBMers and 33% non-IBMers, which I think is quite good given
that we are talking about a mature code base that has been developed by only
IBMers over many years.

Just to be clear, this is real participation in a core piece of Eclipse. We
are certainly not as diverse as for example CDT, but if you compare with
other projects at Eclipse that started with a contribution from a single
company, I believe that we are opening this up pretty successfully. (At
least that is how I like to think about it.)

So in a nutshell, participation is possible and real, and it might even be
rewarding. Talk to e.g. Tom Schindl, Matthew Hall, or Francis Upton if you
want to find out more about how they became committers and why they are
doing it.

Boris
Re: E4 / SWT 4.0 [message #54466 is a reply to message #54329] Fri, 06 June 2008 14:23 Go to previous messageGo to next message
Eclipse User
Originally posted by: eclipse-news.rizzoweb.com

Francis Upton (News) wrote:
> Hi Eric,
>
> I'm just jumping in here, not really knowing the context of this, but I
> want to make a couple of comments to what you say:
>
> 1) The main problem is there are not enough people working on the code
> to get things done. Much of the work is done by the committers, but
> also quite a bit is contributed. But the sum total of that is far less
> than what we need to clean out the bug backlog and satisfy all of the
> requests of the community.
>
> *We need more people doing the work*; it really does not matter if they
> are committers or if they are contributors.

I definitely recognize that (and I think many other people do, though
certainly not everyone who enters his own wish list feature requests).
However, while we hear from one side of the collective project mouth
that more contributors are needed, we hear from the other side of its
mouth how they are spending all this time and effort on e4 planning.
Well, if you have a backlog of bugs and enhancements to an existing code
base, the prudence of moving resources in such critical shortage to a
completely new effort is, well, debatable IMHO. Look at Micro$oft's
history (and the reason many of the MS-haters are haters) for an example.
In short, it is not clear that a complete, ground-up redesign and the
accompanying re-implementing and all the completely new directions, and
<insert-your-favorite-e4-theme> is the best decision. So we need to do a
better job of educating the community about what is happening and the
directions that are being considered and how to become really involved.

>
> I think however we need to get a *lot* better at encouraging
> contributions and contributors. We need more wiki pages and help and
> communication to help people contribute. We need infrastructure for
> this so that all projects can have a lot of materials and support to
> make it easy to document how to contribute, find contributors, recognize
> contributions and contributors, and do a better job of identifying work
> where we need help. Right now it's very uneven between projects because
> there is little in the way of common support for encouraging contributions.

See, I think dedicating the short supply of resources to making those
things happen soon is more prudent than all the work being put into e4
already. How do I voice that concern/desire to someone who can actually
respond with authority? That's a somewhat rhetorical question, but not
100%. And the "why don't you do those things yourself as your
contribution" response is a non-starter here; I'm trying to steer the
discussion away from that canned response and more towards "how can the
existing contributor community better serve the non-contributor community?"

>
> 2) I also think, like any other open source (or many internal
> companies), it's largely a matter of relationships. You can get what
> you want by contributing code certainly; and you can also get what you
> want by working with committers and other contributors and having them
> make things a priority. If you are interested in a particular area,
> then get to know the developers and that's how you will influence
> things. I'm not saying this is right, it's just how things seem to work
> (at least in some areas).

I don't have a problem with that reality - in fact the embracing of
relationships as a fundamental driving force is one of the aspects of
OSS that I, personally, enjoy and consider essential to OSS success in
general.
However, again using myself as an example, there are just often
fundamental differences of attitude/philosophy/perspective that make it
frustrating to break into the clique' of a project. My (least) favorite
example is the SWT/JFace philosophy of minimalism coupled with
backwards-compatibility-at-ALL-cost; it leads to these frameworks
carrying a lot of baggage that makes them simultaneously difficult to
extend and prone to excessive copy+paste coding. I do understand the
driving forces that led to that prevailing philosophy, but I see too
much dogmatism in some areas and too little flexibility in others. This
is an example of a situation where I can try to contribute various
artifacts (from code to design idea to behavioral change suggestions)
but be thwarted at nearly every attempt because of the philosophical
differences (or merely differences in the degree of philosophical dogma).

>
> The problem here is this is entirely a volunteer effort, and yes there
> are full time committers, but their company is effectively volunteering
> their time. Personally, I don't want to see any more elaborate
> mechanisms for prioritizing things or having product mangement, etc
> because that will just add more process overhead.

Agreed, 100%. I think the things that would make the biggest difference
towards engaging the community better and more are things like attitude
and open-mindedness, not things like more committees or policies or
procedures.

Eric
Re: E4 / SWT 4.0 [message #54493 is a reply to message #54414] Fri, 06 June 2008 14:28 Go to previous messageGo to next message
Eclipse User
Originally posted by: eclipse-news.rizzoweb.com

Boris Bokowski wrote:
> But honestly, things are changing. Looking at the list of active committers
> for the Platform project, and more specifically Platform UI (JFace,
> Workbench, IDE), there are six active committers who work for IBM and two
> who don't work for IBM. With Francis joining our team, we will have six vs.
> three, or 66% IBMers and 33% non-IBMers, which I think is quite good given
> that we are talking about a mature code base that has been developed by only
> IBMers over many years.
>
> Just to be clear, this is real participation in a core piece of Eclipse. We
> are certainly not as diverse as for example CDT, but if you compare with
> other projects at Eclipse that started with a contribution from a single
> company, I believe that we are opening this up pretty successfully. (At
> least that is how I like to think about it.)

That is indeed very good and encouraging news. However, is it just an
anomaly (as Ed's diligence in fixing EMF bug reports is), or is there
more evidence of that happening across the board in other Eclipse projects?


> So in a nutshell, participation is possible and real, and it might even be
> rewarding. Talk to e.g. Tom Schindl, Matthew Hall, or Francis Upton if you
> want to find out more about how they became committers and why they are
> doing it.

Can we extrapolate the behaviors, actions, and results of the truly
exceptional to the general population? I think not. I think Eclipse
projects should make it easier for the average community member to
contribute more, even for those who are not as dedicated, talented, and
tenacious as Tom, Matthew, and Francis.

Eric
Re: E4 / SWT 4.0 [message #54519 is a reply to message #54493] Fri, 06 June 2008 15:21 Go to previous messageGo to next message
Boris Bokowski is currently offline Boris Bokowski
Messages: 272
Registered: July 2009
Senior Member
Comments below...

"Eric Rizzo" <eclipse-news@rizzoweb.com> wrote in message
news:g2bvif$ctu$1@build.eclipse.org...
> Boris Bokowski wrote:
>> But honestly, things are changing. Looking at the list of active
>> committers for the Platform project, and more specifically Platform UI
>> (JFace, Workbench, IDE), there are six active committers who work for IBM
>> and two who don't work for IBM. With Francis joining our team, we will
>> have six vs. three, or 66% IBMers and 33% non-IBMers, which I think is
>> quite good given that we are talking about a mature code base that has
>> been developed by only IBMers over many years.
>>
>> Just to be clear, this is real participation in a core piece of Eclipse.
>> We are certainly not as diverse as for example CDT, but if you compare
>> with other projects at Eclipse that started with a contribution from a
>> single company, I believe that we are opening this up pretty
>> successfully. (At least that is how I like to think about it.)
>
> That is indeed very good and encouraging news. However, is it just an
> anomaly (as Ed's diligence in fixing EMF bug reports is), or is there more
> evidence of that happening across the board in other Eclipse projects?

I am seeing it in other projects under the Eclipse top level project,
certainly in PDE for example. I don't know much about how other projects at
Eclipse deal with their contributors. I have filed bugs against other
Eclipse projects myself and was surprised how little reaction I saw for what
I thought were "easy win" kind of bugs.

My hope is that other projects at least follow the Platform laggards ;-)
when it comes to inviting participation and becoming more open for outside
contributors and committers.

>> So in a nutshell, participation is possible and real, and it might even
>> be rewarding. Talk to e.g. Tom Schindl, Matthew Hall, or Francis Upton if
>> you want to find out more about how they became committers and why they
>> are doing it.
>
> Can we extrapolate the behaviors, actions, and results of the truly
> exceptional to the general population? I think not. I think Eclipse
> projects should make it easier for the average community member to
> contribute more, even for those who are not as dedicated, talented, and
> tenacious as Tom, Matthew, and Francis.

I think I argued on my blog that at least for code contributions, we really
need talented contributors because there are just so many things to consider
and so many rules to follow. But I don't think this is a sign that there is
something fundamentally wrong with Eclipse - I am sure that to become a
committer on a core part of Apache, or Firefox, or Linux, you need to be
just as dedicated, talented, and tenacious.

Could it be good enough to attract people like Tom, Matthew, and Francis? We
also had Dave and Brad working on Platform UI, and they were pretty good
too. I don't think these are the only five in the world who would be up to
the task. Maybe what we need is better ways to attract and reward the really
good ones as opposed to the "general population"? I am skeptical if we will
ever be able to use a Wikipedia-like model where everybody can contribute
what they want and somehow the wheat is separated from the chaff over time.

Now coming back to e4, one of the goals of it is to get rid of all the
accidental complexity so that it will become easier to contribute to it.
Just don't expect that this will get rid of all the complexity we have.
Making things perform well, report progress accurately, deal with error
cases properly, avoid deadlocks, or making it easy to use and accessible to
all etc. will always be hard. Not to mention the rules about IP cleanliness,
process considerations, and API compatibility, each of which add another
dimension to the problem of making it easy to contribute.

Boris
Re: E4 / SWT 4.0 [message #54570 is a reply to message #54466] Fri, 06 June 2008 16:05 Go to previous messageGo to next message
Boris Bokowski is currently offline Boris Bokowski
Messages: 272
Registered: July 2009
Senior Member
Two comments below...

"Eric Rizzo" <eclipse-news@rizzoweb.com> wrote in message
news:g2bv8e$qd0$1@build.eclipse.org...
> Francis Upton (News) wrote:
>> Hi Eric,
>>
>> I'm just jumping in here, not really knowing the context of this, but I
>> want to make a couple of comments to what you say:
>>
>> 1) The main problem is there are not enough people working on the code to
>> get things done. Much of the work is done by the committers, but also
>> quite a bit is contributed. But the sum total of that is far less than
>> what we need to clean out the bug backlog and satisfy all of the requests
>> of the community.
>>
>> *We need more people doing the work*; it really does not matter if they
>> are committers or if they are contributors.
>
> I definitely recognize that (and I think many other people do, though
> certainly not everyone who enters his own wish list feature requests).
> However, while we hear from one side of the collective project mouth that
> more contributors are needed, we hear from the other side of its mouth how
> they are spending all this time and effort on e4 planning. Well, if you
> have a backlog of bugs and enhancements to an existing code base, the
> prudence of moving resources in such critical shortage to a completely new
> effort is, well, debatable IMHO. Look at Micro$oft's history (and the
> reason many of the MS-haters are haters) for an example.

I am not sure what exactly you had in mind, but to me, comparable situations
in the history of Microsoft were when they decided to develop Windows
instead of sticking with MS-DOS, or when they completely redesigned Windows
3.11 and went to Windows 95 to make it easier to use, or when they decided
to move everything over to be based on Windows NT to improve security and
reliability. Would you rather that they perfected MS-DOS, or Windows 3.11,
or kept developing Windows 95/98/ME?

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 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.

> In short, it is not clear that a complete, ground-up redesign and the
> accompanying re-implementing and all the completely new directions, and
> <insert-your-favorite-e4-theme> is the best decision. So we need to do a
> better job of educating the community about what is happening and the
> directions that are being considered and how to become really involved.
>
>>
>> I think however we need to get a *lot* better at encouraging
>> contributions and contributors. We need more wiki pages and help and
>> communication to help people contribute. We need infrastructure for this
>> so that all projects can have a lot of materials and support to make it
>> easy to document how to contribute, find contributors, recognize
>> contributions and contributors, and do a better job of identifying work
>> where we need help. Right now it's very uneven between projects because
>> there is little in the way of common support for encouraging
>> contributions.
>
> See, I think dedicating the short supply of resources to making those
> things happen soon is more prudent than all the work being put into e4
> already. How do I voice that concern/desire to someone who can actually
> respond with authority? That's a somewhat rhetorical question, but not
> 100%. And the "why don't you do those things yourself as your
> contribution" response is a non-starter here; I'm trying to steer the
> discussion away from that canned response and more towards "how can the
> existing contributor community better serve the non-contributor
> community?"
>
>>
>> 2) I also think, like any other open source (or many internal companies),
>> it's largely a matter of relationships. You can get what you want by
>> contributing code certainly; and you can also get what you want by
>> working with committers and other contributors and having them make
>> things a priority. If you are interested in a particular area, then get
>> to know the developers and that's how you will influence things. I'm not
>> saying this is right, it's just how things seem to work (at least in some
>> areas).
>
> I don't have a problem with that reality - in fact the embracing of
> relationships as a fundamental driving force is one of the aspects of OSS
> that I, personally, enjoy and consider essential to OSS success in
> general.
> However, again using myself as an example, there are just often
> fundamental differences of attitude/philosophy/perspective that make it
> frustrating to break into the clique' of a project. My (least) favorite
> example is the SWT/JFace philosophy of minimalism coupled with
> backwards-compatibility-at-ALL-cost; it leads to these frameworks carrying
> a lot of baggage that makes them simultaneously difficult to extend and
> prone to excessive copy+paste coding. I do understand the driving forces
> that led to that prevailing philosophy, but I see too much dogmatism in
> some areas and too little flexibility in others. This is an example of a
> situation where I can try to contribute various artifacts (from code to
> design idea to behavioral change suggestions) but be thwarted at nearly
> every attempt because of the philosophical differences (or merely
> differences in the degree of philosophical dogma).

It is hard to argue against you when you claim that people on the SWT or
JFace teams are dogmatic. When I perceive people as dogmatic, I like to err
on the safe side and assume that there are good reasons for their behaviour
or belief that I just don't understand yet. Until I understand all the
reasons, at which point it is much easier to discuss concrete technical
points rather than calling someone dogmatic. (Then there is the possibility
that someone is dogmatic for no good reason, but is extremely rare IMO.)

>
>>
>> The problem here is this is entirely a volunteer effort, and yes there
>> are full time committers, but their company is effectively volunteering
>> their time. Personally, I don't want to see any more elaborate
>> mechanisms for prioritizing things or having product mangement, etc
>> because that will just add more process overhead.
>
> Agreed, 100%. I think the things that would make the biggest difference
> towards engaging the community better and more are things like attitude
> and open-mindedness, not things like more committees or policies or
> procedures.
>
> Eric
>
Re: E4 / SWT 4.0 [message #54594 is a reply to message #54570] Mon, 09 June 2008 04:31 Go to previous messageGo to next message
Eclipse User
Originally posted by: mauro.molinari.cardinis.com

Hello to all.
I'll try to give my personal and humble opinion on this theme.
I'll start from a sentence by Boris.

Boris Bokowski ha scritto:
> I am not sure what exactly you had in mind, but to me, comparable situations
> in the history of Microsoft were when they decided to develop Windows
> instead of sticking with MS-DOS, or when they completely redesigned Windows
> 3.11 and went to Windows 95 to make it easier to use, or when they decided
> to move everything over to be based on Windows NT to improve security and
> reliability. Would you rather that they perfected MS-DOS, or Windows 3.11,
> or kept developing Windows 95/98/ME?

I understand your point of view, but... I don't think Eclipse NOW is
like MS-DOS at the times of Windows 95. I think Eclipse is still a great
modern piece of software, while MS-DOS was not in 1995.

Speaking more generally, I partially agree with Eric, in the sense that
I also experienced some difficulty to communicate with (in particular)
JDT developers in the sense that some request enhancements of mine were
just closed because "not in scope"... One day I also started to wonder
what actually were in scope for e4, but only recently I read something
about this topic on InfoQ.

Maybe the most significant example is this:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=204231
In that request enhancement, I suggested the creation of a tool to edit
resource bundles, providing a hint of a third party existing tool (no
longer updated) that has all the features I would need from such a tool.
Well, the bug was initially closed after TEN minutes as WONTFIX because
there were no plan to add a new editor for properties (although what I
meant was totally different from the existing one).
After complaining, I got it to be reopened, but I was left with very
scarce hope...

Then, after some months, I just discovered by chance that the developer
of the tool I suggested was involved in the development of Eclipse Babel
project..............!!! So, I think this means that my request was not
so foolish...

Turning back to e4, I don't think, as Boris says, that ALL the bugs of
Eclipse 3.x should be fixed before thinking of new features for e4, but
I also think that there are some important bugs and enhancement requests
that, once fixed, would make Eclipse "almost perfect" (please, let me
use this hazardous expression).

Eclipse has already some GREAT features that other software don't have,
but is in some way penalized by some "minor" problems (minor compared to
what Eclipse is already able to do!) that make it harder than necessary
to use in many scenarios. Try to develop a HUGE web application, for
instance, and you'll understand what I mean. Or try to play with
classpath issues when you are working with thousand classes... Or,
again, try to use Eclipse in a complex project structure scenario, where
not all the team members use Eclipse to develop your application and/or
your application is HUGE and built up of many sub-modules...

I think that an Eclipse 4 with the most wanted (or most "smart") bug
fixes or enhancement requests from the community, by looking at
bugzilla, would be an excellent result... Instead, I read something
about the idea to push towards the direction of making e4 usable in a
web browser... this sounds dreadful to me, honestly. Unless you plan to
release e4 within some (many?) YEARS and with a LOT of care...

Regarding the difficulty to start contributing, I also think that more
"getting started" guides would help very much. For instance, in my
specific case, my main difficulty to start contributing would be about
the fact that I don't know SWT. So, maybe a "learning path" to follow
would be very precious. But also some high-level technical documents to
make new developers understand how the all thing works: those things you
should (must?) understand before diving into the detail of the code you
want to fix or enhance...

Also, I understand what Eric thinks when he says that a great barrier is
that many people are not allowed to work as volunteers to develop open
source projects like Eclipse. This is my case, too. So, I try to give
help by contributing through newsgroups and bugzilla, sharing my own
experience, so maybe some good ideas for Eclipse could be taken (or at
least evaluated) from people like Eric and me (and many others). I know
it's very hard to find valuable ideas among hundreds of wish-lists
(often written without too much thinking), but I believe this should be
part of the game.

Sorry for the long post.

Mauro.
Re: E4 / SWT 4.0 [message #54621 is a reply to message #54570] Mon, 09 June 2008 08:05 Go to previous messageGo to next message
Eclipse User
Originally posted by: nospam_kowalskilee.gmail.com

Boris Bokowski wrote:
>(Then there is the possibility
> that someone is dogmatic for no good reason, but is extremely rare IMO.)

It would help in understanding during discussion if someone who is
dogmatic would *state the reason* (good or otherwise) for why they are
vociferously holding their stance. :-)

A long time ago, I was in a discussion with a committer about something
that a few of us thought was a perfectly reasonable request for
enhancement. In the Bugzilla discussion, no matter how I asked the
questions and tried to interpret his responses, I couldn't get a sense
of what was the underlying reason he thought he shouldn't entertain the
request in any release. It seemed as if some philosophy was in his
reason, but we came away with no more understanding of what the
philosophy was.

Pragmatically, I recognize that a good reason is "not enough resources
for this request for this release", just as much as "that's not
backwards compatible and would break existing adopters". I do want to
learn what the underlying reasons are, so that I can learn and
contribute more intelligently.

Best regards,
Lee Anne
Re: E4 / SWT 4.0 [message #54653 is a reply to message #54594] Mon, 09 June 2008 08:20 Go to previous messageGo to next message
Eclipse User
Originally posted by: merks.ca.ibm.com

This is a multi-part message in MIME format.
--------------070509050704080601080101
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Mauro,

Comments below.

Mauro Molinari wrote:
> Hello to all.
> I'll try to give my personal and humble opinion on this theme.
> I'll start from a sentence by Boris.
>
> Boris Bokowski ha scritto:
>> I am not sure what exactly you had in mind, but to me, comparable
>> situations in the history of Microsoft were when they decided to
>> develop Windows instead of sticking with MS-DOS, or when they
>> completely redesigned Windows 3.11 and went to Windows 95 to make it
>> easier to use, or when they decided to move everything over to be
>> based on Windows NT to improve security and reliability. Would you
>> rather that they perfected MS-DOS, or Windows 3.11, or kept
>> developing Windows 95/98/ME?
>
> I understand your point of view, but... I don't think Eclipse NOW is
> like MS-DOS at the times of Windows 95. I think Eclipse is still a
> great modern piece of software, while MS-DOS was not in 1995.
Personally I think Eclipse is still in great shape and that Web 2.0
thing is yet another over-hyped trend that's likely to turn out much
different than might appear on the surface. I definitely agree that in
general we ought to fix our problems before we move on to create new
ones with new features. I would have said I agree 100%, and those
aren't idle words, but rather ones I personally back up with actions.
That being said though, I think Boris makes a strong argument that also
bears consideration. If you look at the huge list of bugzillas, you do
get a sense of diminishing returns on the bug fixing theme. Folks could
be busy for a long time just polishing Eclipse without doing anything
truly innovative or exciting. Will a big community form to help with
the polishing effort? I kind of doubt that since it hasn't so far. Can
the polishing effort go on forever without more community involvement?
I kind of doubt that too. How polished is polished enough? When can the
folks who innovated to created Eclipse do something truly innovative and
new again?
>
> Speaking more generally, I partially agree with Eric, in the sense
> that I also experienced some difficulty to communicate with (in
> particular) JDT developers in the sense that some request enhancements
> of mine were just closed because "not in scope"... One day I also
> started to wonder what actually were in scope for e4, but only
> recently I read something about this topic on InfoQ.
I find it frustrating the way many groups handle their bugzillas. How a
project handles newsgroup questions and bugzilla reports is a true
reflection of their attitude to the community. No other words will
speak louder than the actions taken on these two things. Sure people
might actually have an attitude much different than what appears, but
the community can, will, and ought to judge based on actions. I think
the JDT folks are generally doing the best they can with the resource
available...
>
> Maybe the most significant example is this:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=204231
> In that request enhancement, I suggested the creation of a tool to
> edit resource bundles, providing a hint of a third party existing tool
> (no longer updated) that has all the features I would need from such a
> tool. Well, the bug was initially closed after TEN minutes as WONTFIX
> because there were no plan to add a new editor for properties
> (although what I meant was totally different from the existing one).
Such speedy service! :-P I've often noticed that if I deal with
something in a speedy way, that the speed in and of itself will be
judged as either good or bad depending on whether the person liked what
I did. If they don't like it, they consider the speed to make the bad
result even more offensive; if they did like it, they consider the speed
to make the good result even better. So ask yourself, would you have
felt better if it took and hour, a day or a week? If not, then it's not
the ten minutes that bothered you but the wontfix.

Lets consider this whole issue in the context of the JDT bugzilla backlog

https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=NEW& ;bug_status=ASSIGNED&bug_status=REOPENED&email1=& ;emailtype1=substring&emailassigned_to1=1&email2=&am p;emailtype2=substring&emailreporter2=1&bugidtype=in clude&bug_id=&changedin=&votes=&chfieldfrom= &chfieldto=Now&chfieldvalue=&product=JDT&com ponent=UI&short_desc=&short_desc_type=allwordssubstr &long_desc=&long_desc_type=allwordssubstr&keywor ds=&keywords_type=anywords&field0-0-0=noop&type0 -0-0=noop&value0-0-0=&cmdtype=doit&newqueryname= &order=Reuse%252Bsame%252Bsort%252Bas%252Blast%252Btime
< https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=NEW& ;bug_status=ASSIGNED&bug_status=REOPENED&email1=& ;emailtype1=substring&emailassigned_to1=1&email2=&am p;emailtype2=substring&emailreporter2=1&bugidtype=in clude&bug_id=&changedin=&votes=&chfieldfrom= &chfieldto=Now&chfieldvalue=&product=JDT&com ponent=UI&short_desc=&short_desc_type=allwordssubstr &long_desc=&long_desc_type=allwordssubstr&keywor ds=&keywords_type=anywords&field0-0-0=noop&type0 -0-0=noop&value0-0-0=&cmdtype=doit&newqueryname= &order=Reuse%252Bsame%252Bsort%252Bas%252Blast%252Btime>

Scanning through it, this one caught my attention, being bold and in
bright red
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=235799>

https://bugs.eclipse.org/bugs/show_bug.cgi?id=235799

I though, let me try what they describe. It worked fine. Then I looked
more closely at the stack trace and figured, I wonder what I'd need to
do to have a class file that doesn't end in .class? That seems
unrelated to the scenario described. It makes we wonder why this
bugzilla is still open. The fact that there are more than 1200 and that
to revisit each one for even just a minute would take 20 hours makes the
reason a little more clear.

Of course each user just figures their bug report is a small thing and
expects it to be treated that way, but let's be realistic and consider
all the human beings involved. If the JDT project is unlikely ever to
have resource to build a new properties editor with cool new features,
isn't it reasonable that they make that clear by returning the request?
I suppose leaving it open and marking it as something that won't happen
without a contribution is more user friendly. Personally I tend to
return things only if I'd actually not consider it a good thing even if
someone else contributed it and supported it. An ever growing list is
also in and of itself something that takes a quite a lot of time and
effort to manage.

Consider how long it would take to eliminate everything in the above list!
> After complaining, I got it to be reopened, but I was left with very
> scarce hope...
Ah, those ever useful complaints. :-P I'm not saying this in you case,
but some folks figure the more bitterly they complain the more likely
someone will work hard to silence them. Don't take that comment
personally, since I think in your case that really doesn't apply. In
fact, I'm impressed that you took the time to write such a carefully
considered response.

I wonder if at the time you wrote your report if you had a good sense of
exactly how big the wish list already was? I know how frustrating it is
to watch a wish list grow faster than one can ever hope to shrink it...
>
> Then, after some months, I just discovered by chance that the
> developer of the tool I suggested was involved in the development of
> Eclipse Babel project..............!!! So, I think this means that my
> request was not so foolish...
I think you interpret the rejection of your wish list item as a value
judgment on you personally. A friend at university has a line at the
bottom of each note that said "Never attribute to malice that which is
adequately explained by stupidity." I'm not saying anyone did anything
stupid. The more important thing is to be careful about attributing
motivations to actions, especially negative ones...
>
> Turning back to e4, I don't think, as Boris says, that ALL the bugs of
> Eclipse 3.x should be fixed before thinking of new features for e4,
> but I also think that there are some important bugs and enhancement
> requests that, once fixed, would make Eclipse "almost perfect"
> (please, let me use this hazardous expression).
Probably by the time you take the union of the ones that various
different people consider important, you'd end up with the conclusion
that the vast majority must be done.
>
> Eclipse has already some GREAT features that other software don't
> have, but is in some way penalized by some "minor" problems (minor
> compared to what Eclipse is already able to do!) that make it harder
> than necessary to use in many scenarios. Try to develop a HUGE web
> application, for instance, and you'll understand what I mean. Or try
> to play with classpath issues when you are working with thousand
> classes... Or, again, try to use Eclipse in a complex project
> structure scenario, where not all the team members use Eclipse to
> develop your application and/or your application is HUGE and built up
> of many sub-modules...
Many people will complain that Eclipse is too complex. The solution is
always to simplify it by adding more features and capabilities. But of
course having more ways to do something, also generates even more
complexity... Perhaps a major aspect of the problem with huge web
application development is the underlying framework, JEE; it's
difficult to make a silk purse out of this sow's ear. OSGi is
certainly a far simpler container model. I manage a workspace that
normally consists of almost 200 projects with many millions of lines of
code. OSGi's classpath management makes classpath setup a non-issue and
the applications always just run...
>
> I think that an Eclipse 4 with the most wanted (or most "smart") bug
> fixes or enhancement requests from the community, by looking at
> bugzilla, would be an excellent result...
That's just 3.5 or 3.6. It's relative small incremental improvements on
what we have today. The 3.x effort will continue and if the community
gets involved with that as well, we should expect to see a solid and
improved 3.x stream as well as an exciting innovative 4.x stream to lead
us into a long and bright future.
> Instead, I read something about the idea to push towards the direction
> of making e4 usable in a web browser... this sounds dreadful to me,
> honestly. Unless you plan to release e4 within some (many?) YEARS and
> with a LOT of care...
Personally I wish the web thing was not so over hyped. Far too many
people look at e4 and think, it's primarily about getting onto the web.
That's only one aspect and as far as I could tell from the summit,
that's not the primary aspect nor the central theme. We must be doing
something wrong if folks mostly think it's just a web thing...
>
> Regarding the difficulty to start contributing, I also think that more
> "getting started" guides would help very much.
Absolutely. You can't have too much of this. It's also the kind of
thing that the community itself can help produce. Imagine if each
developer who took the painful steps to get started helped add a little
more information to the wiki to help out the next person. That would
really help stimulate the community. The project leaders need to lead
the way, but the community needs to take actions as well.
> For instance, in my specific case, my main difficulty to start
> contributing would be about the fact that I don't know SWT. So, maybe
> a "learning path" to follow would be very precious.
Eclipse is so very big and so daunting when getting started. I'm not
sure one could reasonably expect to contribute to a JDT UI tool without
a lot of background. There are whole books on the subject of SWT, so
just that is a big investment. It seems to me that no matter what we
do, it will never be easy for folks to contribute to JDT. Only the
dedicated will succeed.
> But also some high-level technical documents to make new developers
> understand how the all thing works: those things you should (must?)
> understand before diving into the detail of the code you want to fix
> or enhance...
When I consider this issue closer to home, I stop and think about how
many times folks have complained about the need for more and better
documentation about EMF. I end up listening until I get frustrated but
being ultra diplomatic and wanting to avoid controversy I keep silent.
Oh wait, that's an idealized version of me! :-P I point out somewhat
bitterly that I have a tiny team of people who just can't keep up. No
matter what we do, someone will complain it's not enough. If I have my
two developers spending 3 person years working on a book, you can be
guaranteed that I'm taking documentation seriously, and that it's
happening at the expense of development work. Of course I fully expect
to get complaints that the book costs money and what horrible exploiters
of open source we are to dare to charge money for a book that ought to
be free. And that's on top of complaints that the wish list isn't all
getting done. Oh well, if folks aren't complaining about your project
then either your work is be done or more likely your work is irrelevant,
because relevant work is never done.

So absolutely we need better documentation. We need better getting
started information and better website organization to make it easier to
find. We need a constant stream of more and better. But please
consider the extent to which the community itself can help with these.
Repeating the same message over and over will not help. I can't stand
to hear complaints about EMF documentation anymore, so folks might not
like my reaction, but let them walk in our shoes for a few miles...
>
> Also, I understand what Eric thinks when he says that a great barrier
> is that many people are not allowed to work as volunteers to develop
> open source projects like Eclipse. This is my case, too.
To me, this is the fundamental problem that needs to be fixed as much as
the very real barriers to entry. The barriers all have obvious
solutions and it's just a matter of taking action. But the free riders
in the world (not you, but your organization that profits and benefits
while giving nothing in return, even to the point of prevent you) will
be the death knell of open source...
> So, I try to give help by contributing through newsgroups and
> bugzilla, sharing my own experience, so maybe some good ideas for
> Eclipse could be taken (or at least evaluated) from people like Eric
> and me (and many others). I know it's very hard to find valuable ideas
> among hundreds of wish-lists (often written without too much
> thinking), but I believe this should be part of the game.
I often tell people, we don't have a shortage of good ideas, we have a
shortage of people who can turn the good ideas into actions and
results. It's incredibly frustrating when good ideas can't be turned
into actions. The more good ideas there are, the more frustrating it
is. So yes, we appreciate your good ideas and we are frustrated by
them. We even have our own good ideas that frustrate us...
>
> Sorry for the long post.
It was a good one. I hope nothing I've said makes you feel bad. I know
from the tone of your note that you have nothing but the best of
intentions and of course community values good intentions. To me I read
all this stuff and think to myself, the solutions are so obvious. We
all know what needs to happen. So why doesn't it just happen? Because
there aren't enough people to make it all actually happen. Good people
like you are not just hampered by lack of getting-started information
but also by barriers in your own organization...

Imagine how happy the JDT folks would be if they had twice as many
people working on JDT. Imagine how much value the rest of the world
would derive from that effort. I'm absolutely sure that an hour
invested in JDT pays for itself in improved productivity a hundred fold
or more. But how do we convince people to invest in JDT when they can't
measure their return on investment in hard currency? How do we convince
them they should even bother rather than hope someone else will do it
for free? These are the truly difficult problems that I don't know how
to solve. They won't be solved, I believe, simply by lowering barriers
to entry on our side...
>
> Mauro.


--------------070509050704080601080101
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Mauro,<br>
<br>
Comments below.<br>
<br>
Mauro Molinari wrote:
<blockquote cite="mid:g2ippb$n2m$1@build.eclipse.org" type="cite">Hello
to all.
<br>
I'll try to give my personal and humble opinion on this theme.
<br>
I'll start from a sentence by Boris.
<br>
<br>
Boris Bokowski ha scritto:
<br>
<blockquote type="cite">I am not sure what exactly you had in mind,
but to me, comparable situations in the history of Microsoft were when
they decided to develop Windows instead of sticking with MS-DOS, or
when they completely redesigned Windows 3.11 and went to Windows 95 to
make it easier to use, or when they decided to move everything over to
be based on Windows NT to improve security and reliability.
Re: E4 / SWT 4.0 [message #54680 is a reply to message #54621] Mon, 09 June 2008 08:29 Go to previous messageGo to next message
Eclipse User
Originally posted by: merks.ca.ibm.com

Lee Anne,

I totally agree. Folks ought to be able to articulate their thinking.
Just saying no because I'm an expert and my opinions are important isn't
good enough. As you can imagine, given a sufficiently large group,
you're always going to end up with a few "characters" lacking in social
graces. Of course intelligent people will often disagree, but they'll
be able to have a civil discussion about the finer points of the
disagreement...

I'd ask for the specific case you mention, but I don't think it's so
nice to drag someone through the mud in public. Perhaps you'd like to
share the specific scenario with Boris to understand what's going on.
Treating the community with respect is important and if there are
shortcomings, it's good to fix the concrete instances...


Lee Anne wrote:
> Boris Bokowski wrote:
>> (Then there is the possibility that someone is dogmatic for no good
>> reason, but is extremely rare IMO.)
>
> It would help in understanding during discussion if someone who is
> dogmatic would *state the reason* (good or otherwise) for why they are
> vociferously holding their stance. :-)
>
> A long time ago, I was in a discussion with a committer about
> something that a few of us thought was a perfectly reasonable request
> for enhancement. In the Bugzilla discussion, no matter how I asked the
> questions and tried to interpret his responses, I couldn't get a sense
> of what was the underlying reason he thought he shouldn't entertain
> the request in any release. It seemed as if some philosophy was in his
> reason, but we came away with no more understanding of what the
> philosophy was.
>
> Pragmatically, I recognize that a good reason is "not enough resources
> for this request for this release", just as much as "that's not
> backwards compatible and would break existing adopters". I do want to
> learn what the underlying reasons are, so that I can learn and
> contribute more intelligently.
>
> Best regards,
> Lee Anne
Re: E4 / SWT 4.0 [message #54706 is a reply to message #54594] Mon, 09 June 2008 11:02 Go to previous messageGo to next message
Francis Upton IV is currently offline Francis Upton IV
Messages: 472
Registered: July 2009
Location: Oakland, CA
Senior Member
> Speaking more generally, I partially agree with Eric, in the sense that
> I also experienced some difficulty to communicate with (in particular)
> JDT developers in the sense that some request enhancements of mine were
> just closed because "not in scope"... One day I also started to wonder
> what actually were in scope for e4, but only recently I read something
> about this topic on InfoQ.
>
> Maybe the most significant example is this:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=204231
> In that request enhancement, I suggested the creation of a tool to edit
> resource bundles, providing a hint of a third party existing tool (no
> longer updated) that has all the features I would need from such a tool.
> Well, the bug was initially closed after TEN minutes as WONTFIX because
> there were no plan to add a new editor for properties (although what I
> meant was totally different from the existing one).
> After complaining, I got it to be reopened, but I was left with very
> scarce hope...
>

I have had several interactions with the JDT team on various issues, and
while I have disagreed with them on some things, I have found them to be
very responsive and agreeable to contributions that they could see
make sense (I was able to contribute an extension to LTK undo with their
guidance that solved my problems). It's also apparent from their
attitude and interactions they are very good owners of their components,
as they work very well and want to make sure they continue to work well
for everyone in the long term. This attitude is exactly what you want,
as far as I am concerned and I look forward to continuing to work with them.

Whenever I want something that's not there, I assume I will have to
provide it, if it's something relatively small, I generate submit a
patch with the bug report. If it's something larger, then I will ask if
the thing I want would be accepted as a contribution and outline what a
contribution might look like. Once I get agreement on these points I
make a contribution.

Open source works like that; we (as clients) have no right to demand
anything. We are not paying for anything, and we are lucky that we lot
more than we pay for. However, unlike commercial products, we are able
to contribute our own work.

One of the things we might be able to improve in our community
development is to provide an easy way to identify the projects that want
contributions, so if you can't make the contribution, perhaps there is
someone else who is interested in the same thing or something similar
that's able to. I realize that bugzilla is used to track all of this
stuff and we do have flags for things that we want contributions for,
but maybe all we need is a little more documentation (perhaps just a
wiki page) with some guidance about how to use these.


Re: E4 / SWT 4.0 [message #54736 is a reply to message #54706] Mon, 09 June 2008 12:11 Go to previous messageGo to next message
Eclipse User
Originally posted by: merks.ca.ibm.com

This is a multi-part message in MIME format.
--------------050503040900070305080401
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Francis,

There's the helpwanted keyword. The bugzilla in question is already so
marked...

I tried to help with
https://bugs.eclipse.org/bugs/show_bug.cgi?id=191322 and while my patch
was kind of not so great (it sucked), they helped turn it into a proper
fix. Now I can take better advantage of the great ability to produce
warnings about ill formed Javadoc references. It pays off to make an
effort to contribute.

My experience with the JDT team is that they are totally awesome. JDT
and PDE's support for external folders on the classpath was a lot of
work for them and it's made life so much easier for those of us who need
to bootstrap a runtime:

http://wiki.eclipse.org/EMF/Getting_Source#Developing_on_Ecl ipse_3.4


Francis Upton (News) wrote:
>
>> Speaking more generally, I partially agree with Eric, in the sense
>> that I also experienced some difficulty to communicate with (in
>> particular) JDT developers in the sense that some request
>> enhancements of mine were just closed because "not in scope"... One
>> day I also started to wonder what actually were in scope for e4, but
>> only recently I read something about this topic on InfoQ.
>>
>> Maybe the most significant example is this:
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=204231
>> In that request enhancement, I suggested the creation of a tool to
>> edit resource bundles, providing a hint of a third party existing
>> tool (no longer updated) that has all the features I would need from
>> such a tool. Well, the bug was initially closed after TEN minutes as
>> WONTFIX because there were no plan to add a new editor for properties
>> (although what I meant was totally different from the existing one).
>> After complaining, I got it to be reopened, but I was left with very
>> scarce hope...
>>
>
> I have had several interactions with the JDT team on various issues,
> and while I have disagreed with them on some things, I have found them
> to be very responsive and agreeable to contributions that they could
> see make sense (I was able to contribute an extension to LTK undo with
> their guidance that solved my problems). It's also apparent from
> their attitude and interactions they are very good owners of their
> components, as they work very well and want to make sure they continue
> to work well for everyone in the long term. This attitude is exactly
> what you want, as far as I am concerned and I look forward to
> continuing to work with them.
>
> Whenever I want something that's not there, I assume I will have to
> provide it, if it's something relatively small, I generate submit a
> patch with the bug report. If it's something larger, then I will ask
> if the thing I want would be accepted as a contribution and outline
> what a contribution might look like. Once I get agreement on these
> points I make a contribution.
>
> Open source works like that; we (as clients) have no right to demand
> anything. We are not paying for anything, and we are lucky that we
> lot more than we pay for. However, unlike commercial products, we are
> able to contribute our own work.
>
> One of the things we might be able to improve in our community
> development is to provide an easy way to identify the projects that
> want contributions, so if you can't make the contribution, perhaps
> there is someone else who is interested in the same thing or something
> similar that's able to. I realize that bugzilla is used to track all
> of this stuff and we do have flags for things that we want
> contributions for, but maybe all we need is a little more
> documentation (perhaps just a wiki page) with some guidance about how
> to use these.


--------------050503040900070305080401
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Francis,<br>
<br>
There's the helpwanted keyword.
Re: E4 / SWT 4.0 [message #54818 is a reply to message #54680] Mon, 09 June 2008 18:17 Go to previous messageGo to next message
Eclipse User
Originally posted by: nospam_kowalskilee.gmail.com

Hi Ed, thanks for your speedy response. :-)

I agree with not railing about someone in public, which is why I didn't
cite the Bugzilla entry or name the area in question.

And because the specific scenario occurred quite a few releases ago, and
the particular committer has moved on, it's not a concrete instance to
fix. I will keep your suggestion to contact Boris, just in case I run
into it again.

My main point though was that those of us who more often wear the
"Eclipse adopter/user" hat oftentimes don't know that we don't know all
of the reasons why a committer would reject or ignore something--while
at the same time, the committers might think all those things are
"intuitively obvious". :-) So the committers don't realize that we're
asking for things based on our perspective and not from the perspective
of someone who knows all the ins and outs of the code or architecture.

Thanks,
Lee Anne


Ed Merks wrote:
> Lee Anne,
>
> I totally agree. Folks ought to be able to articulate their thinking.
> Just saying no because I'm an expert and my opinions are important isn't
> good enough. As you can imagine, given a sufficiently large group,
> you're always going to end up with a few "characters" lacking in social
> graces. Of course intelligent people will often disagree, but they'll
> be able to have a civil discussion about the finer points of the
> disagreement...
>
> I'd ask for the specific case you mention, but I don't think it's so
> nice to drag someone through the mud in public. Perhaps you'd like to
> share the specific scenario with Boris to understand what's going on.
> Treating the community with respect is important and if there are
> shortcomings, it's good to fix the concrete instances...
>
>
Re: E4 / SWT 4.0 [message #54845 is a reply to message #54818] Mon, 09 June 2008 21:48 Go to previous messageGo to next message
Boris Bokowski is currently offline Boris Bokowski
Messages: 272
Registered: July 2009
Senior Member
"Lee Anne" <nospam_kowalskilee@gmail.com> wrote in message
news:g2k9u8$nrh$1@build.eclipse.org...
> ...
> And because the specific scenario occurred quite a few releases ago, and
> the particular committer has moved on, it's not a concrete instance to
> fix. I will keep your suggestion to contact Boris, just in case I run into
> it again.

Yes, please do - I'd be happy to "mediate" if you feel that a committer on
Eclipse Platform/JDT/PDE rejects a contribution without reason, or ignores
something important.

> My main point though was that those of us who more often wear the "Eclipse
> adopter/user" hat oftentimes don't know that we don't know all of the
> reasons why a committer would reject or ignore something--while at the
> same time, the committers might think all those things are "intuitively
> obvious". :-) So the committers don't realize that we're asking for things
> based on our perspective and not from the perspective of someone who knows
> all the ins and outs of the code or architecture.

Yes, this seems to be very common. I am sure that in the past, I have marked
bugs as wontfix or invalid without giving a full explanation as to why I
made that decision. Sometimes, all it takes is another comment in bugzilla
asking why, in a polite way. This is what I do when I don't understand the
reaction for a bug that I reported, and sometimes it works pretty well.

Boris
Re: E4 / SWT 4.0 [message #54872 is a reply to message #54570] Tue, 10 June 2008 11:32 Go to previous messageGo to next message
Eclipse User
Originally posted by: eclipse-news.rizzoweb.com

Boris Bokowski wrote:
> "Eric Rizzo" <eclipse-news@rizzoweb.com> wrote in message
> news:g2bv8e$qd0$1@build.eclipse.org...
>> Francis Upton (News) wrote:
>>>
>>> *We need more people doing the work*; it really does not matter if they
>>> are committers or if they are contributors.
>> I definitely recognize that (and I think many other people do, though
>> certainly not everyone who enters his own wish list feature requests).
>> However, while we hear from one side of the collective project mouth that
>> more contributors are needed, we hear from the other side of its mouth how
>> they are spending all this time and effort on e4 planning. Well, if you
>> have a backlog of bugs and enhancements to an existing code base, the
>> prudence of moving resources in such critical shortage to a completely new
>> effort is, well, debatable IMHO. Look at Micro$oft's history (and the
>> reason many of the MS-haters are haters) for an example.
>
> I am not sure what exactly you had in mind, but to me, comparable situations
> in the history of Microsoft were when they decided to develop Windows
> instead of sticking with MS-DOS, or when they completely redesigned Windows
> 3.11 and went to Windows 95 to make it easier to use, or when they decided
> to move everything over to be based on Windows NT to improve security and
> reliability. Would you rather that they perfected MS-DOS, or Windows 3.11,
> or kept developing Windows 95/98/ME?
>
> 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.


> 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 ;-)

Eric
Re: E4 / SWT 4.0 [message #54899 is a reply to message #54570] Tue, 10 June 2008 11:42 Go to previous messageGo to next message
Eclipse User
Originally posted by: eclipse-news.rizzoweb.com

Boris Bokowski wrote:
> "Eric Rizzo" <eclipse-news@rizzoweb.com> wrote in message
>> However, again using myself as an example, there are just often
>> fundamental differences of attitude/philosophy/perspective that make it
>> frustrating to break into the clique' of a project. My (least) favorite
>> example is the SWT/JFace philosophy of minimalism coupled with
>> backwards-compatibility-at-ALL-cost; it leads to these frameworks carrying
>> a lot of baggage that makes them simultaneously difficult to extend and
>> prone to excessive copy+paste coding. I do understand the driving forces
>> that led to that prevailing philosophy, but I see too much dogmatism in
>> some areas and too little flexibility in others. This is an example of a
>> situation where I can try to contribute various artifacts (from code to
>> design idea to behavioral change suggestions) but be thwarted at nearly
>> every attempt because of the philosophical differences (or merely
>> differences in the degree of philosophical dogma).
>
> It is hard to argue against you when you claim that people on the SWT or
> JFace teams are dogmatic. When I perceive people as dogmatic, I like to err
> on the safe side and assume that there are good reasons for their behaviour
> or belief that I just don't understand yet. Until I understand all the
> reasons, at which point it is much easier to discuss concrete technical
> points rather than calling someone dogmatic. (Then there is the possibility
> that someone is dogmatic for no good reason, but is extremely rare IMO.)

If you are trying to "argue against" me then you have missed my point
entirely (probably mostly due to my inability to express it
effectively). This is not supposed to be an argument; rather, it is
supposed to be an honest exchange of observations and perspectives (at
least, that is the direction in which I am hoping to take it).
My fundamental point behind this discussion is to raise awareness that
the attitudes of argument and defending are contributing to the
barrier-to-entry for community members to become contributors. I respect
the work the various project teams have done and continue to do, but
also think they need a bit of notice that one of the reasons they don't
get more contributors is because of the attitudes and the difficulty in
breaking into the "inner circle" of acceptance as a contributor.

I'm very grateful that at least some of the project leads are
participating in this discussion, but would like to see more, and, more
importantly, am dismayed if you think you need to argue with me because
that means I'm obviously not adequately expressing the points I want to.

Eric
Re: E4 / SWT 4.0 [message #54926 is a reply to message #54899] Tue, 10 June 2008 12:05 Go to previous messageGo to next message
Eclipse User
Originally posted by: merks.ca.ibm.com

Eric,

Just keep in mind that Boris is on the JFace team and your comment
suggested that he might personally be dogmatic. You can't really fault
someone for being defensive when they perceive there to be unjust
criticism. Gosh, people get defensive even when there is fair
criticism. I can assure you from personal experience, that Boris is
neither dogmatic nor inflexible...

I think it's a good thing that this issue generated a lot of
discussion. It's important that all the different perspectives be
considered carefully. Perception is reality after all...


Eric Rizzo wrote:
> Boris Bokowski wrote:
>> "Eric Rizzo" <eclipse-news@rizzoweb.com> wrote in message
>>> However, again using myself as an example, there are just often
>>> fundamental differences of attitude/philosophy/perspective that make
>>> it frustrating to break into the clique' of a project. My (least)
>>> favorite example is the SWT/JFace philosophy of minimalism coupled
>>> with backwards-compatibility-at-ALL-cost; it leads to these
>>> frameworks carrying a lot of baggage that makes them simultaneously
>>> difficult to extend and prone to excessive copy+paste coding. I do
>>> understand the driving forces that led to that prevailing
>>> philosophy, but I see too much dogmatism in some areas and too
>>> little flexibility in others. This is an example of a situation
>>> where I can try to contribute various artifacts (from code to design
>>> idea to behavioral change suggestions) but be thwarted at nearly
>>> every attempt because of the philosophical differences (or merely
>>> differences in the degree of philosophical dogma).
>>
>> It is hard to argue against you when you claim that people on the SWT
>> or JFace teams are dogmatic. When I perceive people as dogmatic, I
>> like to err on the safe side and assume that there are good reasons
>> for their behaviour or belief that I just don't understand yet. Until
>> I understand all the reasons, at which point it is much easier to
>> discuss concrete technical points rather than calling someone
>> dogmatic. (Then there is the possibility that someone is dogmatic for
>> no good reason, but is extremely rare IMO.)
>
> If you are trying to "argue against" me then you have missed my point
> entirely (probably mostly due to my inability to express it
> effectively). This is not supposed to be an argument; rather, it is
> supposed to be an honest exchange of observations and perspectives (at
> least, that is the direction in which I am hoping to take it).
> My fundamental point behind this discussion is to raise awareness that
> the attitudes of argument and defending are contributing to the
> barrier-to-entry for community members to become contributors. I
> respect the work the various project teams have done and continue to
> do, but also think they need a bit of notice that one of the reasons
> they don't get more contributors is because of the attitudes and the
> difficulty in breaking into the "inner circle" of acceptance as a
> contributor.
>
> I'm very grateful that at least some of the project leads are
> participating in this discussion, but would like to see more, and,
> more importantly, am dismayed if you think you need to argue with me
> because that means I'm obviously not adequately expressing the points
> I want to.
>
> Eric
Re: E4 / SWT 4.0 [message #54953 is a reply to message #54653] Tue, 10 June 2008 12:04 Go to previous messageGo to next message
Eclipse User
Originally posted by: eclipse-news.rizzoweb.com

Ed Merks wrote:
<lots of good stuff>

I agreed with and appreciated so much of what Ed has said in this
thread, but this part jumped out at me:

> When I consider this issue closer to home, I stop and think about how
> many times folks have complained about the need for more and better
> documentation about EMF. I end up listening until I get frustrated but
> being ultra diplomatic and wanting to avoid controversy I keep silent.
> Oh wait, that's an idealized version of me! :-P I point out somewhat
> bitterly that I have a tiny team of people who just can't keep up. No
> matter what we do, someone will complain it's not enough. If I have my
> two developers spending 3 person years working on a book, you can be
> guaranteed that I'm taking documentation seriously, and that it's
> happening at the expense of development work. Of course I fully expect
> to get complaints that the book costs money and what horrible exploiters
> of open source we are to dare to charge money for a book that ought to
> be free. And that's on top of complaints that the wish list isn't all
> getting done. Oh well, if folks aren't complaining about your project
> then either your work is be done or more likely your work is irrelevant,
> because relevant work is never done.

Right you are; you and your team should be glad there are so many
requests and personal priorities thrown at you. It's kind of like the
saying, "I welcome growing old, because the alternative is very
unpleasant" ;-)

However, the choice you describe to dedicate 3 man-years to writing a
book is an excellent example of the kind of opaqueness that I think
needs to be addressed. Ed, if you'll indulge me, put on your thick skin
for a moment as I blatantly criticize a decision you made...

Why was that huge investment made into an effort that is largely
obsolete? I mean, my perception is that books are no longer the source
of choice for most developers because the production cycle is just too
long and their accessibility is just too limited. That time would,
IMNSHO, have been much better invested in producing online documentation
of the form that has been proposed in this thread. Plus, your team could
have benefited from the community by providing the foundation on which
the community could more easily build. What I mean is that one of the
biggest hurdles to writing docs is building the momentum, the outlines
and other fundamental structure to give people an idea of how to write
the details, examples to look at, and a list of what remains unfinished
(and thus what needs their help). By doing it in book form, your 2
people were on their own with almost no community help.
Not to mention that the book is already behind (has it even been
published yet?) as EMF 2.4 is on the doorstep.

To fit this into my broader point, I'd say that if the decision of how
to spend team's time on documentation had been more open and advertised,
I would undoubtedly have made the argument above to try to influence the
decision. Maybe you considered the points in my argument on your own,
maybe you didn't; I don't know. Unfortunately, I also don't know of any
mechanism that would have allowed me, as an interested and motivated
community member, to contribute to that particular decision. See what
I'm getting at?

BTW, I'm guessing that the choice for doing a book instead was not based
on financial motivations, since every author I've ever asked tells me
that you don't make money writing a book (especially a technical book).


> So absolutely we need better documentation. We need better getting
> started information and better website organization to make it easier to
> find. We need a constant stream of more and better. But please
> consider the extent to which the community itself can help with these.
> Repeating the same message over and over will not help. I can't stand
> to hear complaints about EMF documentation anymore, so folks might not
> like my reaction, but let them walk in our shoes for a few miles...

Please don't let the endless stream of requests and "psuedo-bugs"
discourage any Eclipse project team members. I think that is a message
that the community should send to the project teams, in exchange for the
project teams' listening to what we have to say about this topic and others.
I wonder how I (and other community members) can broadcast that message
to the project teams, so they don't think all we do is ask, nag, and
complain...

Eric
Re: E4 / SWT 4.0 [message #54980 is a reply to message #54872] Tue, 10 June 2008 12:11 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas Schindl
Messages: 5006
Registered: July 2009
Senior Member
[...]

>> 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

--
B e s t S o l u t i o n . at
------------------------------------------------------------ --------
Tom Schindl JFace-Committer
------------------------------------------------------------ --------
Re: E4 / SWT 4.0 [message #55007 is a reply to message #54953] Tue, 10 June 2008 13:18 Go to previous messageGo to next message
Eclipse User
Originally posted by: merks.ca.ibm.com

Eric,

Comment below.

Eric Rizzo wrote:
> Ed Merks wrote:
> <lots of good stuff>
>
> I agreed with and appreciated so much of what Ed has said in this
> thread, but this part jumped out at me:
>
>> When I consider this issue closer to home, I stop and think about how
>> many times folks have complained about the need for more and better
>> documentation about EMF. I end up listening until I get frustrated
>> but being ultra diplomatic and wanting to avoid controversy I keep
>> silent. Oh wait, that's an idealized version of me! :-P I point out
>> somewhat bitterly that I have a tiny team of people who just can't
>> keep up. No matter what we do, someone will complain it's not
>> enough. If I have my two developers spending 3 person years working
>> on a book, you can be guaranteed that I'm taking documentation
>> seriously, and that it's happening at the expense of development
>> work. Of course I fully expect to get complaints that the book costs
>> money and what horrible exploiters of open source we are to dare to
>> charge money for a book that ought to be free. And that's on top of
>> complaints that the wish list isn't all getting done. Oh well, if
>> folks aren't complaining about your project then either your work is
>> be done or more likely your work is irrelevant, because relevant work
>> is never done.
>
> Right you are; you and your team should be glad there are so many
> requests and personal priorities thrown at you. It's kind of like the
> saying, "I welcome growing old, because the alternative is very
> unpleasant" ;-)
>
> However, the choice you describe to dedicate 3 man-years to writing a
> book is an excellent example of the kind of opaqueness that I think
> needs to be addressed. Ed, if you'll indulge me, put on your thick
> skin for a moment as I blatantly criticize a decision you made...
Oh no. I'm not a pachyderm!
>
> Why was that huge investment made into an effort that is largely
> obsolete?
It wasn't supposed to be a huge investment. Ask Dave and Marcelo. The
schedule just kind of kept stretching and continues to do so.
> I mean, my perception is that books are no longer the source of choice
> for most developers because the production cycle is just too long and
> their accessibility is just too limited.
It's online at Safari...
> That time would, IMNSHO, have been much better invested in producing
> online documentation of the form that has been proposed in this thread.
See, I knew it was coming.
> Plus, your team could have benefited from the community by providing
> the foundation on which the community could more easily build.
It's true.
> What I mean is that one of the biggest hurdles to writing docs is
> building the momentum, the outlines and other fundamental structure to
> give people an idea of how to write the details, examples to look at,
> and a list of what remains unfinished (and thus what needs their
> help). By doing it in book form, your 2 people were on their own with
> almost no community help.
Yes, kind of sad hey.
> Not to mention that the book is already behind (has it even been
> published yet?) as EMF 2.4 is on the doorstep.
That's the second time it's happened. Now writing appendices to cover
2.3 things (generics was a biggy) and 2.4 things like content types and
URI converter enhancements are needed... But the end is nigh!
>
> To fit this into my broader point, I'd say that if the decision of how
> to spend team's time on documentation had been more open and
> advertised, I would undoubtedly have made the argument above to try to
> influence the decision.
At that point I'd have been under the impression that it would be a 2/3
of a person year investment.
> Maybe you considered the points in my argument on your own, maybe you
> didn't; I don't know.
Certainly such things were considered, but a book seems to have some
value as well. It looks good on the resume too. :-P
> Unfortunately, I also don't know of any mechanism that would have
> allowed me, as an interested and motivated community member, to
> contribute to that particular decision. See what I'm getting at?
Yes, we've not been so open. Though at the same time, in my personal
life, I don't appreciate back seat driving...
>
> BTW, I'm guessing that the choice for doing a book instead was not
> based on financial motivations, since every author I've ever asked
> tells me that you don't make money writing a book (especially a
> technical book).
This one will be different. It will be a best seller! :-P I'm not
planning my retirement just yet though...
>
>
>> So absolutely we need better documentation. We need better getting
>> started information and better website organization to make it easier
>> to find. We need a constant stream of more and better. But please
>> consider the extent to which the community itself can help with
>> these. Repeating the same message over and over will not help. I
>> can't stand to hear complaints about EMF documentation anymore, so
>> folks might not like my reaction, but let them walk in our shoes for
>> a few miles...
>
> Please don't let the endless stream of requests and "psuedo-bugs"
> discourage any Eclipse project team members. I think that is a message
> that the community should send to the project teams, in exchange for
> the project teams' listening to what we have to say about this topic
> and others.
> I wonder how I (and other community members) can broadcast that
> message to the project teams, so they don't think all we do is ask,
> nag, and complain...
Try nagging and complaining less. Hehehe. Just kidding!

Usually things like EclipseCon are pretty nice. You get to talk to
people face to face and somehow those personal interactions make a huge
difference. There was one guy, who shall remain nameless, who had been
driving me insane on bugzilla. I wanted to scream about some of the
bugzilla exchanges we had. But when I talked to him at EclipseCon I got
the sense of what a well meaning person he really is. So now when he
opens bugs, I don't cringe just at the sight of his name. He's opened
many very useful bugs that have improved the quality of a number of
different things. I like him now.
>
> Eric
Re: E4 / SWT 4.0 [message #55035 is a reply to message #54926] Tue, 10 June 2008 14:49 Go to previous messageGo to next message
Eclipse User
Originally posted by: eclipse-news.rizzoweb.com

Ed Merks wrote:
> Eric,
>
> Just keep in mind that Boris is on the JFace team and your comment
> suggested that he might personally be dogmatic. You can't really fault
> someone for being defensive when they perceive there to be unjust
> criticism. Gosh, people get defensive even when there is fair
> criticism. I can assure you from personal experience, that Boris is
> neither dogmatic nor inflexible...

Although dogma, as defined in most dictionaries[*], is neither good nor
bad per se, I understand that the word has a certain degree of
negativity in most people's minds. I could have chosen another word to
convey my meaning, perhaps "doctrine" would have been better.
I hope that no one on the JFace/SWT teams were offended, but judging by
his words maybe Boris was a little bit. Hopefully not.

Eric

[*] From http://www.tfd.com/dogma :
2. An authoritative principle, belief, or statement of ideas or
opinion, especially one considered to be absolutely true.
3. A principle or belief or a group of them: "The dogmas of the quiet
past are inadequate to the stormy present" Abraham Lincoln.



> Eric Rizzo wrote:
>> Boris Bokowski wrote:
>>> "Eric Rizzo" <eclipse-news@rizzoweb.com> wrote in message
>>>> However, again using myself as an example, there are just often
>>>> fundamental differences of attitude/philosophy/perspective that make
>>>> it frustrating to break into the clique' of a project. My (least)
>>>> favorite example is the SWT/JFace philosophy of minimalism coupled
>>>> with backwards-compatibility-at-ALL-cost; it leads to these
>>>> frameworks carrying a lot of baggage that makes them simultaneously
>>>> difficult to extend and prone to excessive copy+paste coding. I do
>>>> understand the driving forces that led to that prevailing
>>>> philosophy, but I see too much dogmatism in some areas and too
>>>> little flexibility in others. This is an example of a situation
>>>> where I can try to contribute various artifacts (from code to design
>>>> idea to behavioral change suggestions) but be thwarted at nearly
>>>> every attempt because of the philosophical differences (or merely
>>>> differences in the degree of philosophical dogma).
>>>
>>> It is hard to argue against you when you claim that people on the SWT
>>> or JFace teams are dogmatic. When I perceive people as dogmatic, I
>>> like to err on the safe side and assume that there are good reasons
>>> for their behaviour or belief that I just don't understand yet. Until
>>> I understand all the reasons, at which point it is much easier to
>>> discuss concrete technical points rather than calling someone
>>> dogmatic. (Then there is the possibility that someone is dogmatic for
>>> no good reason, but is extremely rare IMO.)
>>
>> If you are trying to "argue against" me then you have missed my point
>> entirely (probably mostly due to my inability to express it
>> effectively). This is not supposed to be an argument; rather, it is
>> supposed to be an honest exchange of observations and perspectives (at
>> least, that is the direction in which I am hoping to take it).
>> My fundamental point behind this discussion is to raise awareness that
>> the attitudes of argument and defending are contributing to the
>> barrier-to-entry for community members to become contributors. I
>> respect the work the various project teams have done and continue to
>> do, but also think they need a bit of notice that one of the reasons
>> they don't get more contributors is because of the attitudes and the
>> difficulty in breaking into the "inner circle" of acceptance as a
>> contributor.
>>
>> I'm very grateful that at least some of the project leads are
>> participating in this discussion, but would like to see more, and,
>> more importantly, am dismayed if you think you need to argue with me
>> because that means I'm obviously not adequately expressing the points
>> I want to.
>>
>> Eric
Re: E4 / SWT 4.0 [message #55066 is a reply to message #54980] Wed, 11 June 2008 10:42 Go to previous messageGo to next message
Kevin McGuire is currently offline Kevin McGuire
Messages: 12
Registered: July 2009
Junior Member
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
>
Re: E4 / SWT 4.0 [message #55093 is a reply to message #54653] Wed, 11 June 2008 11:07 Go to previous messageGo to next message
Eclipse User
Originally posted by: mauro.molinari.cardinis.com

Hi Ed!

Ed Merks ha scritto:
> Such speedy service! :-P I've often noticed that if I deal with
> something in a speedy way, that the speed in and of itself will be
> judged as either good or bad depending on whether the person liked what
> I did. If they don't like it, they consider the speed to make the bad
> result even more offensive; if they did like it, they consider the speed
> to make the good result even better. So ask yourself, would you have
> felt better if it took and hour, a day or a week? If not, then it's not
> the ten minutes that bothered you but the wontfix.

It was the combination of the "wontfix" and the ten minutes-only spent
to get to that conclusion, because there were "no plans", without giving
too much attention to what my request really was about.

> I wonder if at the time you wrote your report if you had a good sense of
> exactly how big the wish list already was? I know how frustrating it is
> to watch a wish list grow faster than one can ever hope to shrink it...

I know, this is the key point and the challenge. But the "throw away
that list and move on other directions" shouldn't be the right solution
to the problem, IMHO.

> Many people will complain that Eclipse is too complex. The solution is
> always to simplify it by adding more features and capabilities. But of
> course having more ways to do something, also generates even more
> complexity... Perhaps a major aspect of the problem with huge web
> application development is the underlying framework, JEE; it's
> difficult to make a silk purse out of this sow's ear. OSGi is
> certainly a far simpler container model. I manage a workspace that
> normally consists of almost 200 projects with many millions of lines of
> code. OSGi's classpath management makes classpath setup a non-issue and
> the applications always just run...

So, don't you think that if e4 could succeed to manage this complexity
effectively it would be a very good result, without actually the need to
jump to a Web 2.0 infrastructure or any other revolutionary new feature
like that? :-)
Yes, I know you already answered to this question: "there will be
Eclipse 3.5, 3.6, etc."... but if you say that the resources are lacking
for e4, will they be enough to carry on both e4 and e3.x?

> That's just 3.5 or 3.6. It's relative small incremental improvements on
> what we have today. The 3.x effort will continue and if the community
> gets involved with that as well, we should expect to see a solid and
> improved 3.x stream as well as an exciting innovative 4.x stream to lead
> us into a long and bright future.

They are those "small incremental improvements" that frightens me. I
mean, there are some improvements that may seem "small" to an end user
point of view (although VERY valuable), but that are actually hard to
implement. I think they are something in the middle between the
"ordinary maintenance" and the "revolutionary new development"... I
don't think some requested enhancements will ever go into 3.x if e4 is
released without them... And meanwhile, the effort spent on e4 could
have been spent to implement those enhancements...

> I often tell people, we don't have a shortage of good ideas, we have a
> shortage of people who can turn the good ideas into actions and
> results. It's incredibly frustrating when good ideas can't be turned
> into actions. The more good ideas there are, the more frustrating it
> is. So yes, we appreciate your good ideas and we are frustrated by
> them. We even have our own good ideas that frustrate us...

I have no doubts about that! :-)

>> Sorry for the long post.
> It was a good one. I hope nothing I've said makes you feel bad. I know

Not at all, don't worry! :-)
My post wasn't about complaining, but to express my point of view on
this topic.

Cheers,
Mauro.
Re: E4 / SWT 4.0 [message #55145 is a reply to message #55093] Wed, 11 June 2008 14:10 Go to previous message
Eclipse User
Originally posted by: merks.ca.ibm.com

Mauro,

Comments below.


Mauro Molinari wrote:
> Hi Ed!
>
> Ed Merks ha scritto:
>> Such speedy service! :-P I've often noticed that if I deal with
>> something in a speedy way, that the speed in and of itself will be
>> judged as either good or bad depending on whether the person liked
>> what I did. If they don't like it, they consider the speed to make
>> the bad result even more offensive; if they did like it, they
>> consider the speed to make the good result even better. So ask
>> yourself, would you have felt better if it took and hour, a day or a
>> week? If not, then it's not the ten minutes that bothered you but
>> the wontfix.
>
> It was the combination of the "wontfix" and the ten minutes-only spent
> to get to that conclusion, because there were "no plans", without
> giving too much attention to what my request really was about.
I know what you mean. It makes it seem ill considered.
>
>> I wonder if at the time you wrote your report if you had a good sense
>> of exactly how big the wish list already was? I know how frustrating
>> it is to watch a wish list grow faster than one can ever hope to
>> shrink it...
>
> I know, this is the key point and the challenge. But the "throw away
> that list and move on other directions" shouldn't be the right
> solution to the problem, IMHO.
No, I tend to do that only with things that I things are a poor idea
that I'd not want even if it were contributed...
>
>> Many people will complain that Eclipse is too complex. The solution
>> is always to simplify it by adding more features and capabilities.
>> But of course having more ways to do something, also generates even
>> more complexity... Perhaps a major aspect of the problem with huge
>> web application development is the underlying framework, JEE; it's
>> difficult to make a silk purse out of this sow's ear. OSGi is
>> certainly a far simpler container model. I manage a workspace that
>> normally consists of almost 200 projects with many millions of lines
>> of code. OSGi's classpath management makes classpath setup a
>> non-issue and the applications always just run...
>
> So, don't you think that if e4 could succeed to manage this complexity
> effectively it would be a very good result, without actually the need
> to jump to a Web 2.0 infrastructure or any other revolutionary new
> feature like that? :-)
I'm actually personally fine with the way 3.x is on this front. There
are things I don't use yet that I could, like working sets... I see
complexity as a one way trip in general, because it's always solved by
adding more things...
> Yes, I know you already answered to this question: "there will be
> Eclipse 3.5, 3.6, etc."... but if you say that the resources are
> lacking for e4, will they be enough to carry on both e4 and e3.x?
The resources are simply lacking. Folks hope to stimulate renewed
interest to get involved. I think it's actually working. It's sure
generated lots of interesting discussions!
>
>> That's just 3.5 or 3.6. It's relative small incremental improvements
>> on what we have today. The 3.x effort will continue and if the
>> community gets involved with that as well, we should expect to see a
>> solid and improved 3.x stream as well as an exciting innovative 4.x
>> stream to lead us into a long and bright future.
>
> They are those "small incremental improvements" that frightens me. I
> mean, there are some improvements that may seem "small" to an end user
> point of view (although VERY valuable), but that are actually hard to
> implement. I think they are something in the middle between the
> "ordinary maintenance" and the "revolutionary new development"... I
> don't think some requested enhancements will ever go into 3.x if e4 is
> released without them... And meanwhile, the effort spent on e4 could
> have been spent to implement those enhancements...
Yes. Different people will make different trade offs because of a
different sense of priorities.
>
>> I often tell people, we don't have a shortage of good ideas, we have
>> a shortage of people who can turn the good ideas into actions and
>> results. It's incredibly frustrating when good ideas can't be turned
>> into actions. The more good ideas there are, the more frustrating it
>> is. So yes, we appreciate your good ideas and we are frustrated by
>> them. We even have our own good ideas that frustrate us...
>
> I have no doubts about that! :-)
>
>>> Sorry for the long post.
>> It was a good one. I hope nothing I've said makes you feel bad. I know
>
> Not at all, don't worry! :-)
> My post wasn't about complaining, but to express my point of view on
> this topic.
Yes, and it was well expressed.
>
> Cheers,
> Mauro.
Previous Topic:What is the future of RCP?
Next Topic:p2 Webinar - Jul. 15
Goto Forum:
  


Current Time: Thu Apr 17 03:56:18 EDT 2014

Powered by FUDForum. Page generated in 0.04197 seconds