Eclipse Board Election Facts (2010 edition)

You have hopefully seen one of the announcements that the elections for committer representatives for the Eclipse Board of Directors is now open.

Rather than explaining why you should vote for me :-), I thought it would be useful to summarize the key election facts:

• You are voting for a one-year term starting April 2010. Voting is open as of yesterday, for three weeks until March 12, 3 pm Eastern time. Check out the committer candidates and their vision statements.
• To vote, check if you received an email from emo@eclipse.org on Feb 19, 2009. It contains the URL for voting, as well as the required voting password. If you haven't received a voting password, you are probably not (yet) an Eclipse member, and have to sign the membership agreement first. To understand why this is required, read this page, then read this page to make sure you fill out the form correctly. No voting privileges without signing the form!
• The Board will have 20 directors, as follows:
  • Fourteen directors for the strategic members, one seat per member.
  • Three directors from "sustaining members". There are six candidates on which sustaining members (companies) get to vote.
  • Three directors representing the committers. There are five committer candidates.
    

Suffrage

At the risk of playing with words whose connotations I don't fully understand... Eclipse committers have to suffer - a little bit - to be enfranchised. I mean, to get the right to vote in the 2010 Eclipse board member elections, which begin two weeks from today, on February 22, 2010.

If you are an individual (not employed by a member company) committer: Please click here, and sign and send the membership agreement to the Eclipse Foundation. This will enable you to vote in the upcoming board member elections. There is no cost, and as an added bonus, the Eclipse Foundation is now sending really nice thank-you e-mails to those individual committers who become members.

Why should you do that? Let me try to explain with a diagram:

(thanks, diagrammr!)

Here is the same information in text form, copied from the election process web page:

• Each Committer Member gets one vote. Note that committers who are employees of Member companies have all the rights and privileges (including voting) of a Committer Member.

• Individual committers must join the Eclipse Foundation as Committer Members by signing the Membership Agreement in order to be allowed to vote.

• All committers who are employees of a single company have their votes collapsed into a single vote in the committer elections.

That's right: every vote from an individual committer member (someone who signed the individual membership agreement) is worth exactly the same as the votes from all EclipseSource committers combined, or all Oracle committers combined, or all itemis committers combined, ... you get the idea.

That seems a little bit weird, but it sort of makes sense considering the situation back when the rules were made: IBM had way more Eclipse committers than everybody else, and there was a risk that they would determine the committer representatives, who then could be seen as voting in favour of IBM - leading to an imbalance at the board of directors. So when you think about it, the rules ensure that the committer representatives election is truly independent of any potential company interests.

So, to repeat, if you are an individual (not employed by a member company) committer: Please click here, and sign and send the membership agreement to the Eclipse Foundation. It's free (of charge), it will enable you to vote in the upcoming board member elections, and as an added bonus, the Eclipse Foundation is now sending really nice thank-you e-mails to those individual committers who become members.

More votes mean more weight for the committer representatives on the Eclipse Board of Directors. And if you are an individual committer, your vote weighs a lot!

Word definitions.

Suffrage (from the Latin suffragium, meaning "voting tablet", and figuratively "right to vote", and originally a term for the pastern bone used to cast votes) is the civil right to vote, or the exercise of that right.
...
Where Universal suffrage exists, the right to vote is not restricted by race, gender, belief, wealth or social status. It typically does not extend a right to vote to all residents of a region; distinctions are frequently made in regard to citizenship, age, and occasionally mental capacity or criminal convictions.

Can we turn e4 into an orange?

Let me write a quick response to Elias' thought-provoking post. I hope there will be other (and not so quick) responses as well - it is important to step back every now and then to assess whether we are going in the right direction. But for now, I didn't want to let the issues he raises without an answer from the e4 team. The question for me is, how can we turn e4 into a juicy and sweet lemon? ;-)

Killer feature: I fully agree that support for styling and skinning is not going to be enough of a killer feature to convince everybody that it is worth stepping up to e4. What could be other killer features? To be honest, I am not sure. I would be interested in hearing opinions on this - please leave comments!

Download size: The 230 MB are easy to explain - this download includes the 3.x Eclipse SDK (167 MB), the EMF SDK (27 MB), some parts of WTP, GEF, and other bits and pieces. If you just look at the e4 bundles, they amount to just over 2 MB. The dependencies of the core e4 bundles (a subset of those 2 MB) are SWT, JFace, Equinox, and the EMF core runtime. It could always be smaller, but the 230 MB are just the wrong number to look at. Unless you are interested in the footprint of e4 + compatibility layer + everything from the current Eclipse SDK, but clearly it is not the long-term goal of e4 to always ship with everything from 3.x.

Different: This takes a little longer to explain, but luckily a good response already existed, in the form of John Arthorne's argumentation from bug 300099 comment 4 (I made minor adjustments to make it fit better into this blog post):

The purpose of injection was to make it easier to obtain services in the general case, as well as to decouple of service user from knowing or caring about who provided the service. I'll offer a couple of examples that I've taken from the existing 3.x code (all from the current ResourceNavigator.java in 3.6):

1) I want to print a message on the status line. In 3.x this is:

getViewSite().getActionBars().getStatusLineManager().setMessage(msg);

In e4 this should be:

@Inject
IStatusLineManager statusLine;
...
statusLine.setMessage(msg);

2) I want to get the selected resources:

 ArrayList list = new ArrayList();
if (selection instanceof IStructuredSelection) {
  IStructuredSelection ssel = (IStructuredSelection) selection;
  for (Iterator i = ssel.iterator(); i.hasNext();) {
      Object o = i.next();
      IResource resource = null;
      if (o instanceof IResource) {
          resource = (IResource) o;
      } else {
          if (o instanceof IAdaptable) {
              resource = (IResource) ((IAdaptable) o)
                      .getAdapter(IResource.class);
          }
      }
      if (resource != null) {
          list.add(resource);
      }
  }
}
return new StructuredSelection(list);

I'm not sure how we handle multi-selection in e4, but this should be something
like:

 @Inject
public void setSelection(@Named("selection") List<IResource> selection) {
selectedResources = selection;
}

3) I want to associate a help context with my control

    getSite().getWorkbenchWindow().getWorkbench().getHelpSystem().setHelp(
      viewer.getControl(), getHelpContextId());

In e4 this should be something like:

@Inject
IWorkbenchHelpSystem helpSystem;
...
helpSystem.setHelp(viewer.getControl(), getHelpContextId());

The end result is simpler code, but it also removes a mass of assumptions that
the client previously had to make, about what their containment structure
looked like and where specific services came from. I think we sometimes take
for granted how difficult it can be for clients in 3.x to figure out where to
get particular service from.

Having said all that, we have probably gone too far down the
"non-specification" route in e4. I think it is essential that we provide
interfaces containing specification of things clients must implement (e.g., you
need a doSave() method for parts that are to be used as editors). We can make
the interface optional if we want, but there has to be somewhere where we
specify the behavior expected/required for clients. To me this specification of
expected behavior for clients is orthogonal to service injection so I hope that
we can have both.

Sometimes, bug triage is no fun

Here is how I intend to respond to a private email that I received today, about a bug that was filed yesterday. How would you respond in a similar situation?

Hi [X],

Thank you for reporting a problem with Eclipse. But - and maybe it's just me - the private email you sent today comes across as demanding. You are asking us to help you quickly, without investing time on your side to make the problem easy to reproduce for us. I understand that it's frustrating when things don't work the way you think they should work. However, remember that Eclipse is free software, and please consider if you are not already getting a lot more than your money's worth.

So, in your own best interest, could you please use Bugzilla (that way, everybody interested in the issue can follow the discussion), and help us reproduce the problem with as little time investment as possible on our side? I have already asked twice, on the bug, but I will ask one more time: Please attach [a file that will allow us to reproduce the issue] to the bug. I would expect to be able to use [list of steps] to get the source code into my Eclipse. Before uploading the attachment, it wouldn't hurt if you tried the import operation on a fresh workspace to confirm that we will be able to just run it. By the way, the recommended way to produce the file to attach would be [list of steps].

Thanks,
Boris