On 11.06.2012, at 18:44, Mike Milinkovich wrote:
Marcel,
I would like to point out that your #1 requirement below is not in any way unique to research projects. Every open source project wants more publicity and some simple path to building a community. The problem is that there are no easy solutions to these requirements. Whether the project is pure research or commercially backed, making a name for yourself, and attracting adopters and contributors requires a lot of effort.
These are valid points I completely agree with. Being at Eclipse should be something to work hard for. I'm just taking a little more "sweet-tempered" (soft) position to enabling research at Eclipse by giving them a little softer requirements compared to industry projects.
My personal impression is:
I think Eclipse wants more research projects and innovations happen at
eclipse.org.
I also think that this does not happen in the frequency we would like it to happen.
I think many reasons are well known to us already and I'm searching for a solution that takes us closer to the ultimate goal but respects the above requirements to some degree.
Let's take a slightly different approach than before. How about the following:
* Create or reuse a project that has an "incubator" section for research projects.
* All incubator projects get their own git repos and should be pushed gently to use the CBI to get automated builds and test suite execution.
* We set up a common incubator update site that enables all projects to quickly get their ideas out to Eclipse users.
* A common project blog will be accessible for all members to post their announcements for their particular sub-projects etc.
* Committer elections for new incubators are fairly simple: Every new incubator project may name one or two new committers for this particular project.
* Each incubator get's its own section in the homepage to provide new content.
* Incubator projects that are dead for more than a year move to the attic.
* Committers inactive for a year get retired.
* Projects may graduate to independent projects under technology or may decide to become part of the Recommenders project.
* After graduation, projects qualify for joining the release train and potential packings
After writing this, it sounds a bit like the description of the technology top-level project - but with slightly less formal requirements on project creation, tailored for research projects, and little more infrastructure (blog, mailing-list, forums, downloads, build, webpage etc.) to quickly build a community with little less effort. In such a system Incubators still have to take care for their own code. Let's assume for now that researchers at Eclipse wouldn't publish crab, i.e., take care that their products have some quality :)
I think that an approach like the one above is not in conflict with Mike's requirements but could solve some of the problems researchers have. I also think that this wouldn't require any changes to the existing Eclipse infrastructure or polices, and thus, would be minimally intrusive. If the first project comes by that wants under the Eclipse Research Umbrella we create the necessary infrastructure (actually most of it is already there). If things are prepared, Eclipse Foundation may promote this when giving talks at universities or research conferences (e.g., Ralph at ECOOP 2011 in Lancaster).
Just thoughts ;)
Marcel
But I think you already know that, because I've seen how much effort you've put into raising community awareness for Code Recommenders.
The Eclipse Foundation can certainly do more to help, and to make it easier for research projects to find a home at Eclipse. This conversation is an excellent start. There are some very good and pragmatic ideas here that we can work on together. I just wanted to point out that the Eclipse Foundation itself cannot work miracles. We can only implement programs to help projects help themselves to fame, glory, and adoption.
