Some advocates, in an effort to bolster the perceived credibility of their favorite language, look for any sign of support that it may have received from a major corporation as proof that it is not just a passing fad, but is here to stay. Otherwise, they reason, why would this company be investing in it?
Let's not be so naive. Corporations are out to make money. They are not interested in advancing the software development field, championing an ideology or improving your productivity, except in so far as those activities will yield some financial return. If a company appears to be hopping upon your favorite DL's bandwagon, they are simply acknowledging "There is money to be made here." Commercial exploitation is not a hallmark of engineering worth. It will be in many corporations best interests to actively fuel the hype surrounding a DL in order to generate sales of their own related products and services. Hence the advent of the execrable job title "Technology Evangelist".
This is exactly the same position with Your Favourite IDE. It doesn't matter whether it's Eclipse, NetBeans or IntelliJ. Companies are supplying the majority of the committers on these projects (unlike most other open-source projects that exist on SourceForge or Apache). With Eclipse, at least there's diversity; each strategic member (of which there are currently 18) must contribute at least 8 developers to a project, as well as funds for the foundation itself (those Eclipse Award parties don't come cheap, you know). But under the covers, a lot of popular projects are funded with full-time developers from companies that are out to make money by building on top of the basics; whether it's derivative products (Eclipse) or associated services (JBoss).
What it ultimately boils down to is the fact that these full-time people have way, way more time on their hands to achieve goals than the student-at-university (or even ex-student-not-at-university-any-more). I can probably achieve in one month what an Eclipse developer would be able to do before lunch one day; and they'd still have not only the rest of the day, but also the rest of the month left. There's only so many hours in an evening when you return home from work; and a family life is important too. In addition, the EclipseZone stuff is keeping me busy; such as the Getting Started with Eclipse plug-ins series, so that leaves precious little time to work on anything else.
From a practical point of view, whilst a project may be open-source, whenever you contribute code, you're always contributing it to the project as a whole. In some open-source projects, the developers may be many thousands of miles apart; and all the communication is done via e-mail, forums or other on-line activities. If the project is being worked on by ten people in an office, and there's one or two people who occasionally send in ideas from different countries, who is going to have greater impact? (Yes, I know that companies supply members across the globe for the various Eclipse projects, but the majority of those working on the same sub-project are in the same location ... in any case, this isn't specifically about Eclipse.)
Lastly, a lot of companies have invested money in these projects. In some cases, big money. They need their open-source projects to succeed; after all, they're spending a lot of the shareholder's cash in making it happen, and they have to demonstrate a return on investment somewhere (they're not all philanthropic, you know). In fact, some collaborations actually create new markets; there wouldn't be a revenue stream from subversion training if there was no subversion, for example. But it means that these funding companies ultimately call the shots; and there's no way that an unreliable low-time contributor is going to be put on any kind of critical path on the project. At best, they'll be able to do off-shoots or minor bug fixes, but nothing like thinking outside the box of how to make the process or product better all round.
Economists always like to put a value on anything. I think there's a clear value distinction to be made between the kind of hobbyist part-time contributor, and a full-time commercially-funded committer on the same project. It's clear where you should optimise your resources and where the project risk should be contained. That's not to say that the hobbyist contributor can't add any value; but in perspective, it's a tiny proportion compared to the project as a whole.