+1 Kevin.
I'll add that committers play an extra role in specification projects. All patent grants flow through committers. Specifically the necessary rights to implement technology covered by patents held by committers (typically patents held by their employers) are "locked into" the specification on the successful completion of a "check point" review (effectively, a progress or release review). Note that those rights only flow to the implementer when they implement a final specification (i.e, the ratified final form of a specification after the successful completion of a release review).
So... to ensure the flow of patent rights, it's valuable to have at least one committer representative from as many participating member companies as possible. Even if they don't actually do anything.
FWIW, the EFSP has a provision by which a member company that participates in the working group may bypass the usual committer election process appoint a "representative committer". This exists to ensure continuity of the flow of rights. So far, we've only made one such appointment. Note that appointed committers have exactly the same responsibilities and privileges as elected committers.
All committers on a project are equal and must be treated as such. While it is natural to have one or more committers become technical leaders in the project team, there is no formal "technical lead" role. Likewise, I expect that certain members of a project team will become leaders in the specification process, but there is no formal notion of "spec lead". Any de facto "spec lead" does not have any special powers or authority beyond that which is granted to them by the other project committers.
A committer that wishes to retain their status cannot be retired (notwithstanding bad behaviour).
Traditionally, Eclipse projects tended to have a single project lead. It's more the case now that projects have two. More than that is weird, but not strictly wrong. The role of project lead is that of responsibility to ensure that the project team is functioning well according to the terms of the Eclipse Development Process and is observing the Eclipse Intellectual Property Policy. Part of this is to ensure that the "playing field is level" meaning that no single individual (or organization) should be able to dominate a project..
Wayne