Simply models

I have been working on a small demo application that (when finished) is meant to be an exemplary RCP-style desktop application based on e4. This is how it looks so far:

There is a very simple navigator on the left, a thumbnails view, and a preview area.

As I wrote the application based on Eric's and Tom's work, I started by implementing a couple of views that I contributed to the new e4 Workbench through an extension point.

Then I realized that all I need is an EMF model representing the parts that make up the UI: the views, the menu, and the toolbar. I don't actually need any extension points, because my application is not an extensible IDE - it is a rich client application for which I know how the UI should be structured. I am pretty happy about the end result - my application is fully described by one XMI file that I can edit using an editor for EMF models, and I can just go and modify that file if I want to rearrange views, add new ones, delete unnecessary ones, build my menu structure and so on.

Compare this to how it works with the current 3.x Workbench: I would have to write a perspective extension, a couple of views extensions, a command extension, a menu and a toolbar extension. Then I would have to assign unique IDs to all these pieces, and to ensure that IDs match up properly. How many hours we've wasted in the past when IDs did not match up!

Of course, this only works for closed applications, not for open and extensible ones like e.g. the Eclipse IDE. However, it is still pretty useful to be able to reason about a concrete EMF model representing the UI application structure. For example, when you have lots of little pieces contributed by many plug-ins, we can now talk about what it means to produce that concrete model from the many little pieces. One interesting question based on this is: Can we maybe generalize the many ad-hoc mechanisms we have grown over the last years (most of which involve matching up IDs) to something that is less ad-hoc and more general?

It's been fun to work on this little application so far. If you would like to participate, let us know on the e4 mailing list, and/or attend the bi-weekly e4 conference calls. You can always email me directly, of course.

P.S. The code is available in CVS - check out the ui/demos project under /cvsroot/eclipse/e4-incubator to get the launch configuration and project set file (emf-workbench.psf).

Unpaid Volunteers Do Exist

Bjorn blogged about a recent discussion on the SWT and Foundation newsgroups, and claims that Eclipse does not do enough to attract unpaid volunteers.

From my little corner of the ecosystem, I can offer a counterexample. As of today, three of the nine active committers on the Eclipse Platform project's UI component (JFace, Workbench, IDE) are unpaid, part-time volunteers. It seems to be attractive enough to be a Platform committer, at least to some, resulting in 33% active Platform UI committers who are not employees of IBM.

Interestingly, they are all 'unpaid volunteers' (this applies to two more who are not listed as active committers now but were active in the past). They are independent consultants, employed software developers investing some of their spare time, or come from small companies that use Eclipse technology. To me, this contradicts Bjorn's assumption that Eclipse is only 'paid volunteers'. In fact, I would like to understand why in the past, we haven't seen 'paid volunteer' people approach us because they want to contribute to the Platform. (It looks like the e4 effort may change this.)

I admit that we could be more open and transparent over just explaining how to contribute, and hanging out on IRC and the newsgroups. However, what we cannot do is invest a lot of time into contributors who only contribute once (as opposed to ongoing, even if it is part-time). Working with the community on their contributions takes a lot of time. This is why we invest more time on those who may turn into committers at some point: if/when they become committers, we can hope for a return on our time investment.

By the way Bjorn, by disagreeing with one of the replies saying: "this is entirely a volunteer effort", you disagreed with an actual unpaid volunteer, one of the part-time non-IBM committers on the Platform UI component. Francis managed to break through the "glass wall", and the Rizzo Ceiling! I would recommed that you read Francis' post again in this light. ;-P

P.S.
A large part of the high barrier of entry and learning curve is inherent in what we do, and results from all the IP rules, process rules, API compatibility rules, accessibility rules, internationalization rules, performance considerations, architectural integrity considerations, and some more that I probably forgot. I don't think we can do much about this, but I agree with Francis that we need to get a lot better at encouraging contributions and contributors.

e4 summit: May 22nd/23rd

I hope that all interested parties are already subscribed to the e4 mailing list. For those who are not, just an update that we now have a date (May 22nd/23rd, 2008) and a location (Ottawa) for the e4 summit, and that work on the agenda has started. If you are interested in working on the new Platform, please consider attending the summit and add yourself to its wiki page.