Skip to main content

Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Tigerstripe » Why the EMO Approved the Tigerstripe Creation Review
Why the EMO Approved the Tigerstripe Creation Review [message #561880] Sat, 29 December 2007 20:21
Bjorn Freeman-Benson is currently offline Bjorn Freeman-BensonFriend
Messages: 334
Registered: July 2009
Senior Member
This post is in response to the four -1 comments on bug 213493
( and Ed Merk's
blog entry
( ripes.html).
The goal of this essay is to explain why the EMO determined that these
-1s are not justified
( ess.php#6_3_Reviews)
and thus has approved the Tigerstripe project creation.

1. _________ THE EMO IS NEUTRAL _________
Before explaining the EMO's reasoning, I need to respond to and wherein the EMO
is accused of being "both an involved participant in the discussion as
well as the arbiter in the final decision making". Would this be true,
it would be a problem, however upon careful review of the public record
(in the newsgroup echnology.tigerstripe
and on the bug and
on Ed's blog ripes.html),
I found only eight statements by the EMO:

1.1. "Welcome"
1.2. A much shorter version of this longer essay explaining why the EMO
discounts the concerns raised
1.3. A summary of the votes so far
1.4. A retraction of the summary of the votes so far
1.5. A clarification of the process
1.6. A thank you
1.7. An explanation of the EMO's role
1.8. Another explanation of the EMO's role and reasoning ripes.html#c4904527224415955081

None of these statements are even close to being "an involved
participant in the discussion". Thus, on the face of the evidence, I
maintain that the EMO (me) has maintained a careful position of
neutrality and final decision authority as outlined in the processes and

2. _________ THE EMO'S POSITION STATEMENT _________
Next, a few words about the EMO's position on new project creation, not
just this project, but for all projects:

2.1. The EMO can only approve a new project creation if the project fits
within the purposes of the Eclipse Foundation
( _11_10%20Final.pdf).

2.2. There is no single "official modeling story" or "single MDD vision"
from the Eclipse Foundation. No person or group at Eclipse is in charge
of determining what is, or is not, an Eclipse modeling story. The same
goes for any other technology.

2.3. There is no single location for "modeling" projects just like there
is no single location of "widget" projects or "new language IDE"
projects. E.g., SWT has widgets, Nebula has widgets, eRCP has widgets,
DLTK creates new IDEs, IMP creates new IDEs, and CDT creates new IDEs, etc.

2.4. "Competing" projects is not a problem. It's not the best state
(better would be cooperation), but it's also not a problem. We've had
competing projects before and we will again. We believe that the larger
Eclipse community will vote with their feet and choose the best solutions.

2.5. The EMO believes that "code talks, B.S. walks" and that the best
way for a project to prove itself is to operate and deliver as an open
source project. Projects that are open will attract more attention,
contribution and users (e.g. EMF); projects that are closed with wither
and die (e.g., ALF).

The main issue that raises concern for the EMO is when a new proposal is
not clearly interested in becoming an open source projects with open,
transparent, and inclusive participation.

3. _________ THE EXPLICIT NEGATIVE VOTES _________
The comments associated with the explicit negative votes are:

3.1. The current approach will fragment the community

3.2. The current approach will marginalize Tigerstripe

3.3. Technology from M2T and M2M should be used

3.4. A slow migration from an existing code base to an undetermined goal
is far from ideal

3.5. Hard to explain to users which modeling technology to use

3.6. A modeling thing that is not in the modeling top-level and

3.7. Doubts about the project team and their willingness to use existing
Eclipse modeling technology

3.8. Must not duplicate existing modeling projects

Unfortunately, Marcelo's -1
( did not
include a justification, so it will be addressed later.

Addressing each of these explicit statements in order:

3.1. For reasons 2.2 and 2.4, the EMO does not consider this a problem.
We believe that different expert groups (such as the Modeling PMC) will
provide different distros and solutions that appeal to different user
and adopter communities. Eclipse is not in, nor can it be in, the
position of providing a single solution to modeling.

3.2 For reason 2.5, that's a problem for the project and the PMC. The
EMO believes that projects should be given a chance to succeed or fail.

3.3. While this is a good point, for reason 2.4, the EMO doesn't see
this as a blocking issue. We also note that the Tigerstripe team has
said that they will migrate to existing Eclipse modeling technologies

3.4. The EMO agrees that this is not ideal, but "not ideal" is not
grounds for rejecting a new project. We have many new projects that
arrive with an existing code base and evolve from there. Aperi, Babel,
EPF, IMP, and Mayanstall are recent examples.

3.5. For reason 2.2, the EMO does not accept this as a reason to reject
a project.

3.6. For reason 2.3, the EMO does not accept this as a reason to reject
a project. Additionally, the Tigerstripe team did approach the Modeling
PMC first and that PMC rejected them

3.7. See answer to 3.3. The EMO believes that the Tigerstripe team is
serious about migrating – their public statements say that they are. The
EMO cannot find any public information to justify this reason for a veto.

3.8. For reason 2.4, the EMO does not see this as a problem.

I went through all the discussions and gathered all the negative
comments. In this section, I explain why the EMO does not consider these
comments to be blockers for a project creation.

4.1. In
it was stated that Tigerstripe is inferior technology. Similar questions
were raised in,
For reason 2.5, the EMO does not consider inferior technology to be a
disqualifying issue. Additionally, in
the Tigerstripe team disputes the "its all inferior" claim.

4.2. In
and ripes.html
it was stated that Tigerstripe is a brand name which gives it a
threatening appearance. The EMO Executive Director and Legal staff have
resolved the Tigerstripe naming issue (it is being transferred to the
Eclipse Foundation). It seems then that this complaint is that because
Tigerstripe is well known it will threaten the existing Eclipse modeling
projects that are less well known. (Sorry, but the argument wasn't
clearly stated.) The Tigerstripe team replied
( that this was
the best way to avoid losing their existing community while adding on a
new Eclipse community. The EMO does not consider this a problem: either
Tigerstripe will help the Eclipse brand or Tigerstripe will fade away
and be replaced by existing Eclipse modeling sub-brands. Either outcome
is good.

4.3. In ripes.html
there is concern that the proposal does describe all the extension
points. The EMO's position is that "yes, it would be nice if all the
extension points were known apriori, but we've never required that level
of detail from new projects before".

4.4. In,
existing expert Eclipse committers point out that the Tigerstripe
migration plan will require migrating their users at least twice and
that such migration and API refactorings are very hard to do. This is a
serious concern, perhaps the most legitimate critique of the proposal I
found. However, the solution proposed in (that the
project go to Sourceforge and come back later) is so anti- the open
culture we want to encourage at Eclipse that I was almost speechless.
Better was the comment in
that the integration was not early enough in the plan. The EMO felt that
the Tigerstripe team's responses (that they want to migrate and that
they know it is hard and they look forward to advice on the issue)
showed the correct intentions and attitude.

4.5. Another solid critique was in,
a statement that the writer would prefer to the see the Tigerstripe
pieces provided as components rather than a single unified tool. This is
also a strong criticism of the proposal because Eclipse is about
"extensible frameworks and exemplary tools", not about "free tools". The
EMO expects the Tigerstripe team to move in this direction.

4.6. And finally, the question in
of "how will this benefit the Eclipse community?". This is answered by,
statements of support from Eclipse committers and Tigerstripe community

The EMO appreciates the discussion that has happened around this new
project. We believe that the discussion has clarified the proposal
(narrowed the scope), improved the project plan (clarified the goals),
and focused the project team (they understand more about what it means
to be part of Eclipse). All of this is good.

The EMO does not, however, believe that any of the discussion has
provided a valid reason to disqualify Tigerstripe from being an Eclipse
project. Thus the EMO has approved and provisioned the Tigerstripe project.
Previous Topic:Proposed re-phrasing of the proposal
Next Topic:Why the EMO Approved the Tigerstripe Creation Review
Goto Forum:

Current Time: Wed Oct 28 18:30:49 GMT 2020

Powered by FUDForum. Page generated in 0.01898 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top