In his posting All contributions are Equal, some are more equal than others, Robert Konigsberg points out that contributing multiple ways of doing things can easily lead to more user complexity (e.g., by having multiple toString generators).
This is true and in my view, a risk for any system that has many strongly-opinioned contributors (pretty much any large open source project).
Toward the end of his post, he poses a process-level question about how to avoid the situation of some contributions being more equal than others…. I think the solution is the current de facto for Eclipse.org projects and that’s the (frequently unstated) reality that the early bird defines the worm.
When it comes down to it, those that initiate and then follow through on enhancements, fixes, documentation or other contributions get to choose when it comes to actual design decisions. Inevitably, there are design choices that some disagree with, even when all discussion is had completely in the open.
I think the truth of the early bird defines the worm statement is that we should provide incentive to organizations and individuals in the community to be more aggressive about contributing to existing Eclipse projects. This is because waiting for someone else to initiate, design, implement, test and document something often doesn’t work very well.
To some, it may seem like Eclipse Project development is effectively subsidized by others, but this is not true. Even for one’s own usage of Eclipse, contribution and community involvement with Eclipse.org projects pays dividends. There are many ways to contribute, from contributing discussion/ideas, to planning, to new example/app code, to helping to maintain existing code, to documentation, to build support, to testing and bug reporting, to providing bug fixes, to mentoring, and plenty of other kinds of support.
In my view, these are the ways to get your contributions into Eclipse, and influence the community around the software.