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.