For the record, that is not my recollection of the history at
all. Yes, that is perhaps an implicit side-effect. But the primary motivations
that I recall at the time were (in order): (a) to help get projects off to a
better start in understanding the processes and culture of the Eclipse community
and (b) that it was a best practice observed from the Apache Foundation that
had shown some success.
At the time we were getting a lot of new projects at Eclipse and
many – if not most – appeared to floundering. Mentors were an
attempt to provide them with better support in their start-up phase.
I think that it would be mistake to
say "if nobody in the larger Architecture Council wants to be a Mentor,
then we're going to require that the smaller Technology PMC take on that
role". (a) The PMC already has a role to play in each project it sponsors
and (b) the reason the community added the "need two Mentors from the
AC" was to constrain new projects to be only those things that the
broader community (as represented by the AC) is interested in.
You know, I never understood the desire for having mentors in the
first place. Perhaps back when you could create a top-level project from
scratch it made a certain amount of sense. At this point, I would argue that it
is the job of the PMC of the project that accepts a project proposal to mentor
the project. This is especially true for the Technology Project which has
incubation as the primary goal.
Regarding constraining projects, I
cannot even begin to comprehend why this would be a benefit to the community.
The last thing we want to do is to turn Eclipse into a private club where only
people who think in the same way are admitted. Just because no one on the
Architecture Council is interested in a particular project proposal (or has any
time left for mentoring) does not imply that the project proposal is not
viable. As long as we are good about shutting down failed projects, I do not
believe we should be putting in place artificial barriers to admission.