Personally I think that not many academic projects are supported/developed for longer than, say, 6 months. Typically an idea is developed, the tool gets implemented, the paper is written and refined until it gets accepted on a conference – and that's it. As of that time, the software decays. Why? Because success in research is not measured in terms of users but in terms of papers published. And to get papers accepted the software must not work perfectly – it just has to work “a little”.

What is typically missing is the continuous “polishing” to make a tool usable by others. Often, research tools can only be built on the researcher’s machine and not on any other because of hardcoded paths, dependencies etc…
However, there are other projects that aim to create some value (like Mylyn did), which are also very, very interesting (code bubbles clearly belongs to this group). What can Eclipse do to support those projects? Here are my thoughts:

By providing an infrastructure? No.
By helping to create a business? Maybe.
By making such tools known by community? Clearly: Yes.

Three ideas on that:

1. “Beta-Users”
One thing research projects need a lot of is feedback: Is the tool working well? Is it helpful? How do people feel about the tool? What should be improved? What is missing? What bugs exist in the software?

But getting feedback is rather difficult. Making a software open source and put the URL of the issue tracker on the webpage rarely results in a large number of bug reports or, let alone user feedback.

What research projects need are beta-users; people that test your software and provide you with feedback about its usability. Here Eclipse could help in pushing the community to play around with these tools and start discussions on their research topic – maybe such discussions also create one or two project committers.

2. Data
What else can researchers benefit from? Data. Data, Data, Data … and Data Much research needs to collect data about, for instance, how developers traversed source code, used the Eclipse UI, about common programming exceptions when using APIs etc. etc.

The data collector framework is a very interesting tool because it already collects some valuable data. But there is much more that can (need to) be collected in order to solve problems with source code understanding or UI usage as mentioned above.
The following idea is inspired by the SVN team plug-in. After installing the SNV team plug-ins you get a pop-up window that asks you which SVN implementation you want to use (JavaHL, SVNKit etc.). Let’s think about the data collection tool in the same way. Imagine that a developer get’s a pop-up window asking her which open source research project she wants to support today, i.e., share her data with? This way, Eclipse would extremely well support researchers. In this case, academia would contribute special data collectors for the data collector and Eclipse would host the data making it available to researchers.

3. Challenges
Challenges are a great way to see which tools works best for a given problem. Maybe you are aware of tools like XSnippet, Prospector and ParseWeb (few more exist). They all solve the same problem – but they never have been evaluated by a large user community, and thus you will never know how helpful they are in reality. Challenges or community votes could draw the researchers attention to create better tools and at the end the winner gets a nice logo on his webpage “Winner of the Eclipse XY Challenge” (note, that such a thing wouldn’t need a price money – it’s just the honor

However, such user votes are just one idea. Microsoft, for instance, gives away parts of its data for mining bugs. Maybe you know that there are many tools that analyze (and mine) Eclipse code to find bugs. And because of its size, Eclipse is a gladly taken case study for each of them. Creating challenges for Bug Detection tools are also an interesting option where both Eclipse and academia can benefit.

These are my first three ideas that came into my mind after reading you post – and as you might suspect, having such an Eclipse support is greatly appreciated

From the publication perspective, I think it would be useful for Eclipse.org to maintain a list of publications that its technology is mentioned and used in.

EclipseCon could have a track in which researchers would describe their works (2-4 pages), with focus on what Eclipse tools they re-used and what they had created. Editors built with GEF and GMF, DSL editors, RCP applications, and so on.

My wishlist for the next edition: 1:) remote services and 2.) blueprint services

My guess it’s still 100% Google unless that’s changed recently.