Re: [eclipse.org-planning-council] RE: [cross-project-issues-dev] Galile

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

Hi Richard,

Richard Gronback wrote:
> Hi Martin,
>
> Many of the things we’re requiring are just good Eclipse citizenship 
> items that all projects should be striving for anyway. Globalization 
> effort is not only about larger companies or commercial adopters. At 
> least 2 of the 3 communities that all Eclipse projects are supposed to 
> support require this for worldwide consumption. I see these as Eclipse 
> entry requirements, not only as train requirements. See non-code 
> aspects listed on the Release Review checklist: 
> http://wiki.eclipse.org/Development_Resources/HOWTO/Release_Reviews
>
> I can imagine a larger company contributing to a smaller project to 
> get it up to snuff if they are consumers of the project and require it 
> for a commercial product, for example. But, I doubt you’ll find a 
> willingness to contribute for the sake of getting projects on the 
> release train. Instead, we’ll likely just see smaller projects falling 
> off the train, or the respective project leads growing their project 
> team to meet the requirements, and in the process, improving the 
> overall quality/success of their proje

Rich I feel compelled to respond to some apparent assumptions.

First assumption: the stricter rules being proposed imply greater 
quality of all project's output. Although seeming widely believed in 
EF...I don't think this is the case for all projects. For example, 
having a required new and noteworthy (which for my project we've/ECF 
have adopted happily)...for a project like the platform and others, 
obviously yes. But for EMF (e.g.), I personally would rather see Ed 
spend his time on the newsgroup or mailing list answering questions 
directly with users, or working on his book than writing a new and 
noteworthy or a dozen plan.xmls. What I'm trying to say is that the 
*means* to ensure quality (and success for that matter) are based upon a 
number of things...e.g. how many resources are available, what's the 
size of the community around the project, what stage of development it's 
in, what organization is around to help with that community, etc. 
There's a judgment about what's important for the project and community. 
One size doesn't fit all projects/communities.

Second assumption: these rules have anything to do with project success. 
Although it's easy to point to the platform and say 'they were 
successful, so all projects that do things exactly like the platform 
will be successful too'...I don't think that's actually the case.

Third assumption: losing small projects [from the train] isn't a 
significant problem. I think this *is* a big problem, as the small 
projects are (IMHO) the engine of innovation for Eclipse/Eclipse 
Foundation. And as much as I would like it to be so, for small companies 
(and independents) it's not as easy to find contributors...especially 
from outside the company that leads the project (see our old friend 
project diversity).

And also: "I can imagine a larger company contributing to a smaller 
project to get it up to snuff if they are consumers of the project and 
require it for a commercial product, for example"...I also can imagine 
it, but regrettably I haven't seen it happen yet.

Scott