Home » Archived » Board committer reps » Board Meeting
| Board Meeting [message #5010] |
Wed, 13 June 2007 04:58  |
Eclipse User |
|
|
|
Originally posted by: slewis.composent.com
Committer Reps,
I understand there is a Board meeting coming up next week (June 18) and
I want to start a dialog here about what committer issues may be brought
up/discussed before the Board.
Since the squeaky wheel gets the attention :)...as a committer, here are
my 'pet peeves' for the Board:
1) The IP process...for Europa and beyond. I continually have the
impression that all the work of the IP process falls on two groups:
a) the foundation personnel (from outside it seems that more and more
foundation dollars are likely going to feed that monster) and I don't
see how that scales as Ganymede is even bigger than Europa.
b) the committers (who do the work associated with adding license files,
about files, etc. etc.).
The costs (on committers, largely) and benefits (commercial members) are
not equitable IMHO. I understand the benefit to commercial members, but
like I said I think the costs and benefits are not equitably distributed.
2) The lack of company diversity on projects. I still think this is a
particularly insidious problem for the Board and committers...one which
I don't think the strategics or the add-on providers will do anything
about until pushed by the committers/committer reps.
3) The 'project as technical silos' problem. Although related to 2,
it's not the same. Even if projects had representatives from multiple
companies they still might not be cooperating/collaborating across
projects. Especially with Europa, it's becoming clear to me that there
is a lot of duplication of effort/code/work across multiple projects
(e.g. ECF and DSDP and others all doing service discovery stuff, etc).
I don't think this is healthy for the committers in the long term.
4) The lack of membership support for volunteer projects. Does the EF
membership want only corporate run projects? If so, is this a healthy
environment for committers in terms of innovation and interest?
5) Lack of follow-thru of strategic members on membership requirements
WRT people commitment. Each strategic member is required provide a
minimum of 8 committers (See Exhibit B in membership agreement:
http://www.eclipse.org/org/documents/Eclipse%20MEMBERSHIP%20 AGMT%202007_04_04%20Final.pdf).
I'm pretty sure that a good number of the current strategics are not
meeting this requirement (even in name only), and I think the result is
greater burden on the strategics that are, and a greater burden on
smaller orgs and independents.
I suppose that's enough from me for now. I expect/hope that others have
input about what the committers should be discussing at the upcoming
Board meeting...and hopefully they will have the time to discuss some of
their plans in this regard publicly before the actual meeting.
Thanks to Chris, Jeff, Konstantin, Ed, and Darin for representing the
community.
Scott
|
|
|
| Re: Board Meeting [message #5080 is a reply to message #5010] |
Wed, 13 June 2007 12:11  |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Scott,
Thanks. I must confess that so far I think I've been doing a pretty
poor job of being a committer rep. I've been too busy with all my own
(EMF) issues to pay enough attention to the community's issues. As a
group, we are now planning to have a call with Bjorn before each board
meeting to discuss the issues that need attention at the next board
meeting. More comments below...
Scott Lewis wrote:
> Committer Reps,
>
> I understand there is a Board meeting coming up next week (June 18)
> and I want to start a dialog here about what committer issues may be
> brought up/discussed before the Board.
Good idea.
>
> Since the squeaky wheel gets the attention :)...as a committer, here
> are my 'pet peeves' for the Board:
Yes. Speak now or you forfeit the right to complain later. (I haven't
forgotten your issue about needing incubating projects to use parallel IP.)
>
> 1) The IP process...for Europa and beyond. I continually have the
> impression that all the work of the IP process falls on two groups:
>
> a) the foundation personnel (from outside it seems that more and more
> foundation dollars are likely going to feed that monster) and I don't
> see how that scales as Ganymede is even bigger than Europa.
Yesterday we did discuss with Bjorn the lack of resource to handle IP
reviews fast enough. We are all pinched by this and as the IP demands
increase, this problem will only get worse. So personally, before the
board decides to make any more decisions that will increase the IP
burden of the foundation staff, I'd like to be sure that the funding for
that burden is significantly increased.
>
> b) the committers (who do the work associated with adding license
> files, about files, etc. etc.).
It was incredibly frustrating to have this license file debacle take
place at precisely the worst possible time for the committers who needed
to contain it. In the future, the rules should be much more clear, and
we should be addressing it early in the cycle, not during the crazy
shutdown phase. Even the rules themselves are highly questionable.
Having 1,000 copies of the license.html as well as the 1,000 copies
within the properties files is just not a sensible way to distribute a
common and consistent license; translating these files to multiple
languages makes the problem even worse. So we'd like to discuss how to
make this more sensible by referring to a single version at the
foundation (and perhaps with a single local cached copy for disconnected
installations). We should have these discussions early so that a new
set of rules is in place long before the next crazy phase...
>
> The costs (on committers, largely) and benefits (commercial members)
> are not equitable IMHO. I understand the benefit to commercial
> members, but like I said I think the costs and benefits are not
> equitably distributed.
We discussed this issue yesterday as well. Working for IBM, I know there
is a great deal of value in providing an IP clean result that can be
consumed by commercial vendors. But I can see that the burden for
making this happen is extremely onerous to the committer community, many
of whom get little or no direct benefit from this. I'm also concerned
that the battle of the open source licenses (LGPL is bad?) will affect
our community in an adverse way. Sure it's a great thing that Eclipse
builds components that can be used in anywhere, even for commercial
products, but should there be rules that dictate that this is the only
thing it should do, i.e., it should never provide integration with any
LGPL library because LGPL is so inherently bad that we should build a
giant firewall to keep it from tainting our perfectly pure and good EPL
code? I would hope not (because otherwise Teneo could not provide
integration with Hibernate).
>
> 2) The lack of company diversity on projects. I still think this is a
> particularly insidious problem for the Board and committers...one
> which I don't think the strategics or the add-on providers will do
> anything about until pushed by the committers/committer reps.
I'll just climb on my soap box and point out that the modeling project
is a model of diversity and wait for people to contradict me. :-) I
think project diversity is likely a problem specific to each project and
you can't simply tell people to be more diverse and expect it will
happen. I can certainly relate to why people might be concerned about
diversifying their projects. There are lots of fly-by-night people in
this world, and to have code dumped and them left behind is not
something any of us want to handle. All that being said, I think
diversity has great value and we should take steps to make it happen;
it's certainly been a topic of board conversations already. And not to
point any fingers, but starting with the platform as the model of
perfection the rest of ascribe to, would be a good place. We need to
ask ourselves why it is that the platform committer base has not
diversified? I don't think it's purely an issue of people being kept
out. I think many people are more than happy to take a free ride with
occasional fits of wanting to dump their half baked solutions into the
mix. (Feel free to contradict me!)
>
> 3) The 'project as technical silos' problem. Although related to 2,
> it's not the same. Even if projects had representatives from multiple
> companies they still might not be cooperating/collaborating across
> projects. Especially with Europa, it's becoming clear to me that
> there is a lot of duplication of effort/code/work across multiple
> projects (e.g. ECF and DSDP and others all doing service discovery
> stuff, etc). I don't think this is healthy for the committers in the
> long term.
I totally agree. I think part of the problem is that many projects
create one big silo, so if you want a little bag of grain, you need to
haul in the 18 wheeler and take on a full load. Smaller features like
what we did for EMF recently would help. But features really suck and
maintaining them is going to be kind of a nightmare. Perhaps the new
provisioning story will be at least partially a panacea (and doesn't end
up delivering "features" with a new word to label them).
>
> 4) The lack of membership support for volunteer projects. Does the EF
> membership want only corporate run projects? If so, is this a healthy
> environment for committers in terms of innovation and interest?
I don't believe the foundation wants only corporate run projects. But
keep in mind that the dominance of corporate interests at Eclipse is
perhaps significantly driven by the apathy of those with alternative
points of view (and perhaps by the poor job the committer reps do
representing these alternative points of view). You being a notable
exception of course. :-) IBM for one contributes huge sums of money by
funding a large number of committers, so it's understandable that it
will expect its interests to be well served by this large investment.
But many of us also use large portions of our own personal time to make
Eclipse great and I personally work hard to encourage a diverse
community within EMF/EMFT and the modeling project that includes
individuals, smaller companies, and academics. It's up to each of us to
help balance the scales. And we shouldn't be too quick to overlook the
extent to which corporate interests helps facilitate and fund the great
community we are building.
>
> 5) Lack of follow-thru of strategic members on membership requirements
> WRT people commitment. Each strategic member is required provide a
> minimum of 8 committers (See Exhibit B in membership agreement:
> http://www.eclipse.org/org/documents/Eclipse%20MEMBERSHIP%20 AGMT%202007_04_04%20Final.pdf).
> I'm pretty sure that a good number of the current strategics are not
> meeting this requirement (even in name only), and I think the result
> is greater burden on the strategics that are, and a greater burden on
> smaller orgs and independents.
Hopefully some of those folks are reading this and will feel sheepish.
Just as it was time to review every license file we ship (because we'd
all agreed to follow the not-so-clear rules), I think it's time to
review the commitments the strategic members are living up to or not.
It's always unpleasant to embarrass people though. :-(
>
> I suppose that's enough from me for now. I expect/hope that others
> have input about what the committers should be discussing at the
> upcoming Board meeting...and hopefully they will have the time to
> discuss some of their plans in this regard publicly before the actual
> meeting.
Unfortunately I don't think we are so terribly well organized yet.
Right now is an incredibly busy time for us "real developers". It's
reassuring though that all the issues you've brought up in this note
have been points of discussion already...
>
> Thanks to Chris, Jeff, Konstantin, Ed, and Darin for representing the
> community.
>
> Scott
|
|
|
| Re: Board Meeting [message #5147 is a reply to message #5080] |
Wed, 13 June 2007 16:53 |
| Eclipse User |
|
|
|
Originally posted by: slewis.composent.com
Hi Ed,
Thanks for the thoughtful response...a couple of minor comments below.
Ed Merks wrote:
> Scott,
>
> Thanks. I must confess that so far I think I've been doing a pretty
> poor job of being a committer rep. I've been too busy with all my own
> (EMF) issues to pay enough attention to the community's issues. As a
> group, we are now planning to have a call with Bjorn before each board
> meeting to discuss the issues that need attention at the next board
> meeting. More comments below...
>
>
> Scott Lewis wrote:
>> Committer Reps,
>>
>> I understand there is a Board meeting coming up next week (June 18)
>> and I want to start a dialog here about what committer issues may be
>> brought up/discussed before the Board.
> Good idea.
>>
>> Since the squeaky wheel gets the attention :)...as a committer, here
>> are my 'pet peeves' for the Board:
> Yes. Speak now or you forfeit the right to complain later. (I haven't
> forgotten your issue about needing incubating projects to use parallel IP.)
>>
>> 1) The IP process...for Europa and beyond. I continually have the
>> impression that all the work of the IP process falls on two groups:
>>
>> a) the foundation personnel (from outside it seems that more and more
>> foundation dollars are likely going to feed that monster) and I don't
>> see how that scales as Ganymede is even bigger than Europa.
> Yesterday we did discuss with Bjorn the lack of resource to handle IP
> reviews fast enough. We are all pinched by this and as the IP demands
> increase, this problem will only get worse. So personally, before the
> board decides to make any more decisions that will increase the IP
> burden of the foundation staff, I'd like to be sure that the funding for
> that burden is significantly increased.
>>
>> b) the committers (who do the work associated with adding license
>> files, about files, etc. etc.).
> It was incredibly frustrating to have this license file debacle take
> place at precisely the worst possible time for the committers who needed
> to contain it. In the future, the rules should be much more clear, and
> we should be addressing it early in the cycle, not during the crazy
> shutdown phase. Even the rules themselves are highly questionable.
> Having 1,000 copies of the license.html as well as the 1,000 copies
> within the properties files is just not a sensible way to distribute a
> common and consistent license; translating these files to multiple
> languages makes the problem even worse. So we'd like to discuss how to
> make this more sensible by referring to a single version at the
> foundation (and perhaps with a single local cached copy for disconnected
> installations). We should have these discussions early so that a new
> set of rules is in place long before the next crazy phase...
I agree.
>>
>> The costs (on committers, largely) and benefits (commercial members)
>> are not equitable IMHO. I understand the benefit to commercial
>> members, but like I said I think the costs and benefits are not
>> equitably distributed.
> We discussed this issue yesterday as well. Working for IBM, I know there
> is a great deal of value in providing an IP clean result that can be
> consumed by commercial vendors. But I can see that the burden for
> making this happen is extremely onerous to the committer community, many
> of whom get little or no direct benefit from this. I'm also concerned
> that the battle of the open source licenses (LGPL is bad?) will affect
> our community in an adverse way. Sure it's a great thing that Eclipse
> builds components that can be used in anywhere, even for commercial
> products, but should there be rules that dictate that this is the only
> thing it should do, i.e., it should never provide integration with any
> LGPL library because LGPL is so inherently bad that we should build a
> giant firewall to keep it from tainting our perfectly pure and good EPL
> code? I would hope not (because otherwise Teneo could not provide
> integration with Hibernate).
Note I'm personally not as concerned with the restrictions on using
alternative licenses, but I do believe it is a hinderance in some cases
(it has been for my project anyway)...so I do believe it's a significant
issue for committers as well. It holds back innovation because a lot of
innovation takes place in LGPL, GPL and other lands...
>>
>> 2) The lack of company diversity on projects. I still think this is a
>> particularly insidious problem for the Board and committers...one
>> which I don't think the strategics or the add-on providers will do
>> anything about until pushed by the committers/committer reps.
> I'll just climb on my soap box and point out that the modeling project
> is a model of diversity and wait for people to contradict me. :-) I
> think project diversity is likely a problem specific to each project and
> you can't simply tell people to be more diverse and expect it will
> happen. I can certainly relate to why people might be concerned about
> diversifying their projects. There are lots of fly-by-night people in
> this world, and to have code dumped and them left behind is not
> something any of us want to handle. All that being said, I think
> diversity has great value and we should take steps to make it happen;
> it's certainly been a topic of board conversations already. And not to
> point any fingers, but starting with the platform as the model of
> perfection the rest of ascribe to, would be a good place. We need to
> ask ourselves why it is that the platform committer base has not
> diversified? I don't think it's purely an issue of people being kept
> out. I think many people are more than happy to take a free ride with
> occasional fits of wanting to dump their half baked solutions into the
> mix. (Feel free to contradict me!)
I think when the issue is framed as quality vs. project diversity it's
a misrepresentation. I would be the last to suggest that quality of EF
projects should be reduced. But I don't think (as some seem to) that
project diversity necessarily will result in lower quality. Just
because the Platform is of very high quality and it is not very diverse
doesn't mean that project diversity implies lower quality. I think
that's a conflation.
I think the committers as a group should suggest some more
approaches/ideas to maintaining quality while increasing project
diversity. I think the dev process changes approved in january are a
great start (e.g. mentors for projects, etc). Perhaps some peer review
(i.e. committers outside a given project being asked to
use/comment/review APIs, docs, etc).
>>
>> 3) The 'project as technical silos' problem. Although related to 2,
>> it's not the same. Even if projects had representatives from multiple
>> companies they still might not be cooperating/collaborating across
>> projects. Especially with Europa, it's becoming clear to me that
>> there is a lot of duplication of effort/code/work across multiple
>> projects (e.g. ECF and DSDP and others all doing service discovery
>> stuff, etc). I don't think this is healthy for the committers in the
>> long term.
> I totally agree. I think part of the problem is that many projects
> create one big silo, so if you want a little bag of grain, you need to
> haul in the 18 wheeler and take on a full load. Smaller features like
> what we did for EMF recently would help. But features really suck and
> maintaining them is going to be kind of a nightmare. Perhaps the new
> provisioning story will be at least partially a panacea (and doesn't end
> up delivering "features" with a new word to label them).
I didn't mean to impune EMF, Platform or any other project in this
regard...I think the collaboration/cross-project issue is a big and
general one for all foundation projects. But very important for
committer interests like innovation, user satisfaction with all EF
projects and community, etc.
>>
>> 4) The lack of membership support for volunteer projects. Does the EF
>> membership want only corporate run projects? If so, is this a healthy
>> environment for committers in terms of innovation and interest?
> I don't believe the foundation wants only corporate run projects. But
> keep in mind that the dominance of corporate interests at Eclipse is
> perhaps significantly driven by the apathy of those with alternative
> points of view (and perhaps by the poor job the committer reps do
> representing these alternative points of view). You being a notable
> exception of course. :-) IBM for one contributes huge sums of money by
> funding a large number of committers, so it's understandable that it
> will expect its interests to be well served by this large investment.
> But many of us also use large portions of our own personal time to make
> Eclipse great and I personally work hard to encourage a diverse
> community within EMF/EMFT and the modeling project that includes
> individuals, smaller companies, and academics. It's up to each of us to
> help balance the scales. And we shouldn't be too quick to overlook the
> extent to which corporate interests helps facilitate and fund the great
> community we are building.
I don't think I'm overlooking it. I value it highly as well. But I
feel that although money is an important enabler (of course), it doesn't
explain the commitment, dedication, and ownership that comes with the
'founder' role...and in the EF I consider the committers akin to the
'founders' of an organization.
I think the committers, through their 'sweat equity' show a commitment
and dedication that demands more than 'you've been paid for your time,
so we'll take it from here'. Here's a little thought experiment: would
you be working on Eclipse technology even if <your company> didn't exist
and you weren't paid for it? That is, is
Eclipse/WTP/EMF/ECF/DSDP/Corona your avocation as well as your vocation?
I would guess that for many committers (and contributor) the anwswer
would be 'yes'. Independent and voluntary committers are just an
'extreme' form of this demonstrated commitment...as they are dedicated
enough (or perhaps foolish enough :) to work on something they believe
in/like/understand/enjoy/get creative and personal value from, even if
it doesn't provide them with any obvious ROI. I think this is the
laudable insight behind having committer representatives on the Board at
all (how many sw companies have representatives on their Boards for
engineers?).
So anyway, my point is not that the money isn't important...not at all.
...and I don't even mean to minimize it's important. But my point is
that funding alone doesn't imply *total* ownership of the value and
community created by Eclipse. There is a lot of personal creativity and
commitment that is required above and beyond the money...and I think
those contributions imply some respect as well.
Reminds me of Jim Clark (Netscape) famous saying:
"In a ham and egg breakfast, the pig is committed, and the chicken is
not" :)
>>
>> 5) Lack of follow-thru of strategic members on membership requirements
>> WRT people commitment. Each strategic member is required provide a
>> minimum of 8 committers (See Exhibit B in membership agreement:
>> http://www.eclipse.org/org/documents/Eclipse%20MEMBERSHIP%20 AGMT%202007_04_04%20Final.pdf).
>> I'm pretty sure that a good number of the current strategics are not
>> meeting this requirement (even in name only), and I think the result
>> is greater burden on the strategics that are, and a greater burden on
>> smaller orgs and independents.
> Hopefully some of those folks are reading this and will feel sheepish.
> Just as it was time to review every license file we ship (because we'd
> all agreed to follow the not-so-clear rules), I think it's time to
> review the commitments the strategic members are living up to or not.
> It's always unpleasant to embarrass people though. :-(
Not my intention...and I don't want to get any of you 'in trouble'
around this issue. But the 'free rider' problem is important though, I
believe, because I think the committers (and the strategics that are
meeting/exceeding this commitment) are both being implicitly taken
advantage of...and I think this can reduce the sustainability of the
entire community (or at least puts it at greater risk).
>>
>> I suppose that's enough from me for now. I expect/hope that others
>> have input about what the committers should be discussing at the
>> upcoming Board meeting...and hopefully they will have the time to
>> discuss some of their plans in this regard publicly before the actual
>> meeting.
> Unfortunately I don't think we are so terribly well organized yet.
> Right now is an incredibly busy time for us "real developers". It's
> reassuring though that all the issues you've brought up in this note
> have been points of discussion already...
That's good. I don't wish to be an irritant to any/all of the committer
reps...just to help in the connection between all committers and the Board.
Scott
|
|
|
| Re: Board Meeting [message #5216 is a reply to message #5080] |
Wed, 27 June 2007 21:51 |
| Eclipse User |
|
|
|
Originally posted by: slewis.composent.com
Now that Europa is nearly in the can :), any public comments from the
Committer Board reps about the Board meeting last week?
Scott
Ed Merks wrote:
> Scott,
>
> Thanks. I must confess that so far I think I've been doing a pretty
> poor job of being a committer rep. I've been too busy with all my own
> (EMF) issues to pay enough attention to the community's issues. As a
> group, we are now planning to have a call with Bjorn before each board
> meeting to discuss the issues that need attention at the next board
> meeting. More comments below...
>
>
> Scott Lewis wrote:
>> Committer Reps,
>>
>> I understand there is a Board meeting coming up next week (June 18)
>> and I want to start a dialog here about what committer issues may be
>> brought up/discussed before the Board.
> Good idea.
>>
>> Since the squeaky wheel gets the attention :)...as a committer, here
>> are my 'pet peeves' for the Board:
> Yes. Speak now or you forfeit the right to complain later. (I haven't
> forgotten your issue about needing incubating projects to use parallel IP.)
>>
>> 1) The IP process...for Europa and beyond. I continually have the
>> impression that all the work of the IP process falls on two groups:
>>
>> a) the foundation personnel (from outside it seems that more and more
>> foundation dollars are likely going to feed that monster) and I don't
>> see how that scales as Ganymede is even bigger than Europa.
> Yesterday we did discuss with Bjorn the lack of resource to handle IP
> reviews fast enough. We are all pinched by this and as the IP demands
> increase, this problem will only get worse. So personally, before the
> board decides to make any more decisions that will increase the IP
> burden of the foundation staff, I'd like to be sure that the funding for
> that burden is significantly increased.
>>
>> b) the committers (who do the work associated with adding license
>> files, about files, etc. etc.).
> It was incredibly frustrating to have this license file debacle take
> place at precisely the worst possible time for the committers who needed
> to contain it. In the future, the rules should be much more clear, and
> we should be addressing it early in the cycle, not during the crazy
> shutdown phase. Even the rules themselves are highly questionable.
> Having 1,000 copies of the license.html as well as the 1,000 copies
> within the properties files is just not a sensible way to distribute a
> common and consistent license; translating these files to multiple
> languages makes the problem even worse. So we'd like to discuss how to
> make this more sensible by referring to a single version at the
> foundation (and perhaps with a single local cached copy for disconnected
> installations). We should have these discussions early so that a new
> set of rules is in place long before the next crazy phase...
>>
>> The costs (on committers, largely) and benefits (commercial members)
>> are not equitable IMHO. I understand the benefit to commercial
>> members, but like I said I think the costs and benefits are not
>> equitably distributed.
> We discussed this issue yesterday as well. Working for IBM, I know there
> is a great deal of value in providing an IP clean result that can be
> consumed by commercial vendors. But I can see that the burden for
> making this happen is extremely onerous to the committer community, many
> of whom get little or no direct benefit from this. I'm also concerned
> that the battle of the open source licenses (LGPL is bad?) will affect
> our community in an adverse way. Sure it's a great thing that Eclipse
> builds components that can be used in anywhere, even for commercial
> products, but should there be rules that dictate that this is the only
> thing it should do, i.e., it should never provide integration with any
> LGPL library because LGPL is so inherently bad that we should build a
> giant firewall to keep it from tainting our perfectly pure and good EPL
> code? I would hope not (because otherwise Teneo could not provide
> integration with Hibernate).
>>
>> 2) The lack of company diversity on projects. I still think this is a
>> particularly insidious problem for the Board and committers...one
>> which I don't think the strategics or the add-on providers will do
>> anything about until pushed by the committers/committer reps.
> I'll just climb on my soap box and point out that the modeling project
> is a model of diversity and wait for people to contradict me. :-) I
> think project diversity is likely a problem specific to each project and
> you can't simply tell people to be more diverse and expect it will
> happen. I can certainly relate to why people might be concerned about
> diversifying their projects. There are lots of fly-by-night people in
> this world, and to have code dumped and them left behind is not
> something any of us want to handle. All that being said, I think
> diversity has great value and we should take steps to make it happen;
> it's certainly been a topic of board conversations already. And not to
> point any fingers, but starting with the platform as the model of
> perfection the rest of ascribe to, would be a good place. We need to
> ask ourselves why it is that the platform committer base has not
> diversified? I don't think it's purely an issue of people being kept
> out. I think many people are more than happy to take a free ride with
> occasional fits of wanting to dump their half baked solutions into the
> mix. (Feel free to contradict me!)
>>
>> 3) The 'project as technical silos' problem. Although related to 2,
>> it's not the same. Even if projects had representatives from multiple
>> companies they still might not be cooperating/collaborating across
>> projects. Especially with Europa, it's becoming clear to me that
>> there is a lot of duplication of effort/code/work across multiple
>> projects (e.g. ECF and DSDP and others all doing service discovery
>> stuff, etc). I don't think this is healthy for the committers in the
>> long term.
> I totally agree. I think part of the problem is that many projects
> create one big silo, so if you want a little bag of grain, you need to
> haul in the 18 wheeler and take on a full load. Smaller features like
> what we did for EMF recently would help. But features really suck and
> maintaining them is going to be kind of a nightmare. Perhaps the new
> provisioning story will be at least partially a panacea (and doesn't end
> up delivering "features" with a new word to label them).
>>
>> 4) The lack of membership support for volunteer projects. Does the EF
>> membership want only corporate run projects? If so, is this a healthy
>> environment for committers in terms of innovation and interest?
> I don't believe the foundation wants only corporate run projects. But
> keep in mind that the dominance of corporate interests at Eclipse is
> perhaps significantly driven by the apathy of those with alternative
> points of view (and perhaps by the poor job the committer reps do
> representing these alternative points of view). You being a notable
> exception of course. :-) IBM for one contributes huge sums of money by
> funding a large number of committers, so it's understandable that it
> will expect its interests to be well served by this large investment.
> But many of us also use large portions of our own personal time to make
> Eclipse great and I personally work hard to encourage a diverse
> community within EMF/EMFT and the modeling project that includes
> individuals, smaller companies, and academics. It's up to each of us to
> help balance the scales. And we shouldn't be too quick to overlook the
> extent to which corporate interests helps facilitate and fund the great
> community we are building.
>>
>> 5) Lack of follow-thru of strategic members on membership requirements
>> WRT people commitment. Each strategic member is required provide a
>> minimum of 8 committers (See Exhibit B in membership agreement:
>> http://www.eclipse.org/org/documents/Eclipse%20MEMBERSHIP%20 AGMT%202007_04_04%20Final.pdf).
>> I'm pretty sure that a good number of the current strategics are not
>> meeting this requirement (even in name only), and I think the result
>> is greater burden on the strategics that are, and a greater burden on
>> smaller orgs and independents.
> Hopefully some of those folks are reading this and will feel sheepish.
> Just as it was time to review every license file we ship (because we'd
> all agreed to follow the not-so-clear rules), I think it's time to
> review the commitments the strategic members are living up to or not.
> It's always unpleasant to embarrass people though. :-(
>>
>> I suppose that's enough from me for now. I expect/hope that others
>> have input about what the committers should be discussing at the
>> upcoming Board meeting...and hopefully they will have the time to
>> discuss some of their plans in this regard publicly before the actual
>> meeting.
> Unfortunately I don't think we are so terribly well organized yet.
> Right now is an incredibly busy time for us "real developers". It's
> reassuring though that all the issues you've brought up in this note
> have been points of discussion already...
>>
>> Thanks to Chris, Jeff, Konstantin, Ed, and Darin for representing the
>> community.
>>
>> Scott
|
|
|
| Re: Board Meeting [message #5287 is a reply to message #5216] |
Thu, 28 June 2007 12:00 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
This is a multi-part message in MIME format.
--------------080201060509090002060501
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Scott,
Sure, set me up to publicly break board confidentiality. :-) There
were discussions at the meeting about confidentiality but I think most
of us are still not very comfortable with where the dividing line is.
It's clearly inappropriate to talk about "he said this" and "she said
that" though. Such information should come only from the published
minutes after the board has voted to approve the publication of those
minutes. I'm hopeful that minutes will be published more promptly,
i.e., within four weeks of the meeting, so that will help a bit.
IP discussions where certainly a dominant theme at this board meeting,
both as a committer rep issue and as an issue brought to the board at
the plenary session by the planning council. We'd all like to see
things run more smoothly with less delays and it looks like additional
staff is in the works; we're applying pressure for still more. :-)
Parallel IP is very popular, and many of us would like to see it applied
more broadly. As such, we are taking further steps to investigate how
that can be enabled without compromising the integrity and confidence
folks have that when they download something from Eclipse, their legal
concerns are nonexistent. So expect to hear more on this front in the
coming months. We've also committed to work more closely with Janet and
her IP team to help improve the current processes and to define new ones
so as to ensure more of an element of predictability to the handling of
IP reviews and to have less redundancy in the legal files that are
distributed. It's a big challenge for such a small team and under the
circumstances, they are doing the best they can with the resources
available to accomplish the foundation's goals. An interesting thing to
keep in mind is that while a developer is comfortable saying something
will take a week and have it end up taking three weeks, legal folks feel
more like their word is a legal contract. ;-)
There were long discussions about changes to the IP policy to deal with
what are characterized as "depends-on" verses "works-with"
dependencies. There were a great number of concerns with the initial
wording, so we had a fun time doing committee wordsmithing to end up
with a result I think everyone was comfortable with. I had specific
concerns with regard to Teneo's use of Hibernate in this regard. It's
important to the foundation that projects generally provide deliverables
that are effectively full function without a requirement for the
installation of components with a license incompatible with EPL (since
that leaves most commercial vendors in a bind). It think the board has
done a good job balancing this need against the desire to also provide
integration with well-established popular LGPL software.
Project diversity is definitely a concern for many but it's clear that
you can't simply require diversity and expect it to happen. Among the
things that are needed are things each project could help do. I.e.,
clear instructions of how to set up an image from CVS (a team project
set) so that patches can be produced, and clear instructions for how to
set up and run the JUnits so that patches are sound and so that new
JUnits to test them are provided. The platform team is committed to
helping move in the right direction, but each project is in excellent
position to help with that. I understand that VE is attracting some new
committers; it's an example where lack of diversity has clearly hurt not
only that project but Eclipse as a whole by virtue of affecting how well
rounded its offerings are...
The committer reps talked about the project silo issues and there was
some talk about a "commons" project, but not all of us were comfortable
with that idea. I think the fundamental problem is that the boxes
themselves set up boundaries so creating new boxes does not solve the
boundaries problem. In my opinion, only finer grained builds and
distributions will help truly bring the barriers down. Within the
modeling space, we have a very large number of small components, so we
are learning to manage the build infrastructure to support this and we
are more than happy to share the results with the rest of the
community. Nick has done amazing things for us and we can now get new
components started rapidly. For example, check out how cool our search
CVS facility is.
http://www.eclipse.org/modeling/emf/searchcvs.php?q=194088
All that's required is to include [<bugzilla-number>] in the CVS commit
comment, and you get automatic release notes published with each build
along with the ability to see the CVS delta for each and every one in
your web browser.
In terms of volunteer projects, that's kind of difficult issue. You
can't really force people to volunteer, or they wouldn't be
volunteering. :-) But I'm hopeful that the foundation will eventually
have a bit more money to staff the building of infrastructure that
supports the common good. As committers, there's an awful lot we can do
ourselves in this regard.
And finally, I did raise the issue of strategic member commitments and
I'm hopeful that in the not-to-distant future the web page that lists
all the strategic members will include an up-to-date list of the people
that each member has committed towards full time work at Eclipse. We
have a few privacy issues to tackle before we can put that in place.
Overall I was *extremely *happy with how the board meetings went. The
board is populated by a very constructive group of people who work well
together. They are very responsive to committer issues so any
perception that committer issues take a back seat are definitely unfounded.
Was there anything else specifically you wanted to hear more about?
Scott Lewis wrote:
> Now that Europa is nearly in the can :), any public comments from the
> Committer Board reps about the Board meeting last week?
>
> Scott
>
>
> Ed Merks wrote:
>> Scott,
>>
>> Thanks. I must confess that so far I think I've been doing a pretty
>> poor job of being a committer rep. I've been too busy with all my
>> own (EMF) issues to pay enough attention to the community's issues.
>> As a group, we are now planning to have a call with Bjorn before each
>> board meeting to discuss the issues that need attention at the next
>> board meeting. More comments below...
>>
>>
>> Scott Lewis wrote:
>>> Committer Reps,
>>>
>>> I understand there is a Board meeting coming up next week (June 18)
>>> and I want to start a dialog here about what committer issues may be
>>> brought up/discussed before the Board.
>> Good idea.
>>>
>>> Since the squeaky wheel gets the attention :)...as a committer, here
>>> are my 'pet peeves' for the Board:
>> Yes. Speak now or you forfeit the right to complain later. (I
>> haven't forgotten your issue about needing incubating projects to use
>> parallel IP.)
>>>
>>> 1) The IP process...for Europa and beyond. I continually have the
>>> impression that all the work of the IP process falls on two groups:
>>>
>>> a) the foundation personnel (from outside it seems that more and
>>> more foundation dollars are likely going to feed that monster) and I
>>> don't see how that scales as Ganymede is even bigger than Europa.
>> Yesterday we did discuss with Bjorn the lack of resource to handle IP
>> reviews fast enough. We are all pinched by this and as the IP
>> demands increase, this problem will only get worse. So personally,
>> before the board decides to make any more decisions that will
>> increase the IP burden of the foundation staff, I'd like to be sure
>> that the funding for that burden is significantly increased.
>>>
>>> b) the committers (who do the work associated with adding license
>>> files, about files, etc. etc.).
>> It was incredibly frustrating to have this license file debacle take
>> place at precisely the worst possible time for the committers who
>> needed to contain it. In the future, the rules should be much more
>> clear, and we should be addressing it early in the cycle, not during
>> the crazy shutdown phase. Even the rules themselves are highly
>> questionable. Having 1,000 copies of the license.html as well as the
>> 1,000 copies within the properties files is just not a sensible way
>> to distribute a common and consistent license; translating these
>> files to multiple languages makes the problem even worse. So we'd
>> like to discuss how to make this more sensible by referring to a
>> single version at the foundation (and perhaps with a single local
>> cached copy for disconnected installations). We should have these
>> discussions early so that a new set of rules is in place long before
>> the next crazy phase...
>>>
>>> The costs (on committers, largely) and benefits (commercial members)
>>> are not equitable IMHO. I understand the benefit to commercial
>>> members, but like I said I think the costs and benefits are not
>>> equitably distributed.
>> We discussed this issue yesterday as well. Working for IBM, I know
>> there is a great deal of value in providing an IP clean result that
>> can be consumed by commercial vendors. But I can see that the burden
>> for making this happen is extremely onerous to the committer
>> community, many of whom get little or no direct benefit from this.
>> I'm also concerned that the battle of the open source licenses (LGPL
>> is bad?) will affect our community in an adverse way. Sure it's a
>> great thing that Eclipse builds components that can be used in
>> anywhere, even for commercial products, but should there be rules
>> that dictate that this is the only thing it should do, i.e., it
>> should never provide integration with any LGPL library because LGPL
>> is so inherently bad that we should build a giant firewall to keep it
>> from tainting our perfectly pure and good EPL code? I would hope not
>> (because otherwise Teneo could not provide integration with Hibernate).
>>>
>>> 2) The lack of company diversity on projects. I still think this is
>>> a particularly insidious problem for the Board and committers...one
>>> which I don't think the strategics or the add-on providers will do
>>> anything about until pushed by the committers/committer reps.
>> I'll just climb on my soap box and point out that the modeling
>> project is a model of diversity and wait for people to contradict
>> me. :-) I think project diversity is likely a problem specific to
>> each project and you can't simply tell people to be more diverse and
>> expect it will happen. I can certainly relate to why people might be
>> concerned about diversifying their projects. There are lots of
>> fly-by-night people in this world, and to have code dumped and them
>> left behind is not something any of us want to handle. All that
>> being said, I think diversity has great value and we should take
>> steps to make it happen; it's certainly been a topic of board
>> conversations already. And not to point any fingers, but starting
>> with the platform as the model of perfection the rest of ascribe to,
>> would be a good place. We need to ask ourselves why it is that the
>> platform committer base has not diversified? I don't think it's
>> purely an issue of people being kept out. I think many people are
>> more than happy to take a free ride with occasional fits of wanting
>> to dump their half baked solutions into the mix. (Feel free to
>> contradict me!)
>>>
>>> 3) The 'project as technical silos' problem. Although related to 2,
>>> it's not the same. Even if projects had representatives from
>>> multiple companies they still might not be cooperating/collaborating
>>> across projects. Especially with Europa, it's becoming clear to me
>>> that there is a lot of duplication of effort/code/work across
>>> multiple projects (e.g. ECF and DSDP and others all doing service
>>> discovery stuff, etc). I don't think this is healthy for the
>>> committers in the long term.
>> I totally agree. I think part of the problem is that many projects
>> create one big silo, so if you want a little bag of grain, you need
>> to haul in the 18 wheeler and take on a full load. Smaller features
>> like what we did for EMF recently would help. But features really
>> suck and maintaining them is going to be kind of a nightmare.
>> Perhaps the new provisioning story will be at least partially a
>> panacea (and doesn't end up delivering "features" with a new word to
>> label them).
>>>
>>> 4) The lack of membership support for volunteer projects. Does the
>>> EF membership want only corporate run projects? If so, is this a
>>> healthy environment for committers in terms of innovation and interest?
>> I don't believe the foundation wants only corporate run projects.
>> But keep in mind that the dominance of corporate interests at Eclipse
>> is perhaps significantly driven by the apathy of those with
>> alternative points of view (and perhaps by the poor job the committer
>> reps do representing these alternative points of view). You being a
>> notable exception of course. :-) IBM for one contributes huge sums
>> of money by funding a large number of committers, so it's
>> understandable that it will expect its interests to be well served by
>> this large investment. But many of us also use large portions of our
>> own personal time to make Eclipse great and I personally work hard to
>> encourage a diverse community within EMF/EMFT and the modeling
>> project that includes individuals, smaller companies, and academics.
>> It's up to each of us to help balance the scales. And we shouldn't
>> be too quick to overlook the extent to which corporate interests
>> helps facilitate and fund the great community we are building.
>>>
>>> 5) Lack of follow-thru of strategic members on membership
>>> requirements WRT people commitment. Each strategic member is
>>> required provide a minimum of 8 committers (See Exhibit B in
>>> membership agreement:
>>> http://www.eclipse.org/org/documents/Eclipse%20MEMBERSHIP%20 AGMT%202007_04_04%20Final.pdf).
>>> I'm pretty sure that a good number of the current strategics are
>>> not meeting this requirement (even in name only), and I think the
>>> result is greater burden on the strategics that are, and a greater
>>> burden on smaller orgs and independents.
>> Hopefully some of those folks are reading this and will feel
>> sheepish. Just as it was time to review every license file we ship
>> (because we'd all agreed to follow the not-so-clear rules), I think
>> it's time to review the commitments the strategic members are living
>> up to or not. It's always unpleasant to embarrass people though. :-(
>>>
>>> I suppose that's enough from me for now. I expect/hope that others
>>> have input about what the committers should be discussing at the
>>> upcoming Board meeting...and hopefully they will have the time to
>>> discuss some of their plans in this regard publicly before the
>>> actual meeting.
>> Unfortunately I don't think we are so terribly well organized yet.
>> Right now is an incredibly busy time for us "real developers". It's
>> reassuring though that all the issues you've brought up in this note
>> have been points of discussion already...
>>>
>>> Thanks to Chris, Jeff, Konstantin, Ed, and Darin for representing
>>> the community.
>>>
>>> Scott
--------------080201060509090002060501
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Scott,<br>
<br>
Sure, set me up to publicly break board confidentiality. :-) There
were discussions at the meeting about confidentiality but I think most
of us are still not very comfortable with where the dividing line is.
It's clearly inappropriate to talk about "he said this" and "she said
that" though. Such information should come only from the published
minutes after the board has voted to approve the publication of those
minutes. I'm hopeful that minutes will be published more promptly,
i.e., within four weeks of the meeting, so that will help a bit.<br>
<br>
IP discussions where certainly a dominant theme at this board meeting,
both as a committer rep issue and as an issue brought to the board at
the plenary session by the planning council. We'd all like to see
things run more smoothly with less delays and it looks like additional
staff is in the works; we're applying pressure for still more. :-)
Parallel IP is very popular, and many of us would like to see it
applied more broadly. As such, we are taking further steps to
investigate how that can be enabled without compromising the integrity
and confidence folks have that when they download something from
Eclipse, their legal concerns are nonexistent. So expect to hear more
on this front in the coming months. We've also committed to work more
closely with Janet and her IP team to help improve the current
processes and to define new ones so as to ensure more of an element of
predictability to the handling of IP reviews and to have less
redundancy in the legal files that are distributed. It's a big
challenge for such a small team and under the circumstances, they are
doing the best they can with the resources available to accomplish the
foundation's goals. An interesting thing to keep in mind is that while
a developer is comfortable saying something will take a week and have
it end up taking three weeks, legal folks feel more like their word is
a legal contract. ;-)<br>
<br>
There were long discussions about changes to the IP policy to deal with
what are characterized as "depends-on" verses "works-with"
dependencies. There were a great number of concerns with the initial
wording, so we had a fun time doing committee wordsmithing to end up
with a result I think everyone was comfortable with. I had specific
concerns with regard to Teneo's use of Hibernate in this regard. It's
important to the foundation that projects generally provide
deliverables that are effectively full function without a requirement
for the installation of components with a license incompatible with EPL
(since that leaves most commercial vendors in a bind). It think the
board has done a good job balancing this need against the desire to
also provide integration with well-established popular LGPL software.<br>
<br>
Project diversity is definitely a concern for many but it's clear that
you can't simply require diversity and expect it to happen. Among the
things that are needed are things each project could help do. I.e.,
clear instructions of how to set up an image from CVS (a team project
set) so that patches can be produced, and clear instructions for how to
set up and run the JUnits so that patches are sound and so that new
JUnits to test them are provided. The platform team is committed to
helping move in the right direction, but each project is in excellent
position to help with that. I understand that VE is attracting some
new committers; it's an example where lack of diversity has clearly
hurt not only that project but Eclipse as a whole by virtue of
affecting how well rounded its offerings are...<br>
<br>
The committer reps talked about the project silo issues and there was
some talk about a "commons" project, but not all of us were comfortable
with that idea. I think the fundamental problem is that the boxes
themselves set up boundaries so creating new boxes does not solve the
boundaries problem. In my opinion, only finer grained builds and
distributions will help truly bring the barriers down. Within the
modeling space, we have a very large number of small components, so we
are learning to manage the build infrastructure to support this and we
are more than happy to share the results with the rest of the
community. Nick has done amazing things for us and we can now get new
components started rapidly. For example, check out how cool our search
CVS facility is. <br>
<blockquote><a
href="http://www.eclipse.org/modeling/emf/searchcvs.php?q=194088">http://www.eclipse.org/modeling/emf/searchcvs.php?q=194088</a><br>
</blockquote>
All that's required is to include [<bugzilla-number>] in the CVS
commit comment, and you get automatic release notes published with each
build along with the ability to see the CVS delta for each and every
one in your web browser.<br>
<br>
In terms of volunteer projects, that's kind of difficult issue. You
can't really force people to volunteer, or they wouldn't be
volunteering. :-) But I'm hopeful that the foundation will
eventually have a bit more money to staff the building of
infrastructure that supports the common good. As committers, there's
an awful lot we can do ourselves in this regard.<br>
<br>
And finally, I did raise the issue of strategic member commitments and
I'm hopeful that in the not-to-distant future the web page that lists
all the strategic members will include an up-to-date list of the people
that each member has committed towards full time work at Eclipse. We
have a few privacy issues to tackle before we can put that in place.<br>
<br>
Overall I was <b>extremely </b>happy with how the board meetings
went. The
board is populated by a very constructive group of people who work well
together. They are very responsive to committer issues so any
perception that committer issues take a back seat are definitely
unfounded.<br>
<br>
Was there anything else specifically you wanted to hear more about?<br>
<br>
<br>
Scott Lewis wrote:
<blockquote cite="mid:f5um5r$1ki$1@build.eclipse.org" type="cite">Now
that Europa is nearly in the can :), any public comments from the
Committer Board reps about the Board meeting last week?
<br>
<br>
Scott
<br>
<br>
<br>
Ed Merks wrote:
<br>
<blockquote type="cite">Scott,
<br>
<br>
Thanks. I must confess that so far I think I've been doing a pretty
poor job of being a committer rep. I've been too busy with all my own
(EMF) issues to pay enough attention to the community's issues. As a
group, we are now planning to have a call with Bjorn before each board
meeting to discuss the issues that need attention at the next board
meeting. More comments below...
<br>
<br>
<br>
Scott Lewis wrote:
<br>
<blockquote type="cite">Committer Reps,
<br>
<br>
I understand there is a Board meeting coming up next week (June 18) and
I want to start a dialog here about what committer issues may be
brought up/discussed before the Board.
<br>
</blockquote>
Good idea.
<br>
<blockquote type="cite"><br>
Since the squeaky wheel gets the attention :)...as a committer, here
are my 'pet peeves' for the Board:
<br>
</blockquote>
Yes. Speak now or you forfeit the right to complain later. (I haven't
forgotten your issue about needing incubating projects to use parallel
IP.)
<br>
<blockquote type="cite"><br>
1) The IP process...for Europa and beyond. I continually have the
impression that all the work of the IP process falls on two groups:
<br>
<br>
a) the foundation personnel (from outside it seems that more and more
foundation dollars are likely going to feed that monster) and I don't
see how that scales as Ganymede is even bigger than Europa.
<br>
</blockquote>
Yesterday we did discuss with Bjorn the lack of resource to handle IP
reviews fast enough. We are all pinched by this and as the IP demands
increase, this problem will only get worse. So personally, before the
board decides to make any more decisions that will increase the IP
burden of the foundation staff, I'd like to be sure that the funding
for that burden is significantly increased.
<br>
<blockquote type="cite"><br>
b) the committers (who do the work associated with adding license
files, about files, etc. etc.).
<br>
</blockquote>
It was incredibly frustrating to have this license file debacle take
place at precisely the worst possible time for the committers who
needed to contain it. In the future, the rules should be much more
clear, and we should be addressing it early in the cycle, not during
the crazy shutdown phase. Even the rules themselves are highly
questionable. Having 1,000 copies of the license.html as well as the
1,000 copies within the properties files is just not a sensible way to
distribute a common and consistent license; translating these files to
multiple languages makes the problem even worse. So we'd like to
discuss how to make this more sensible by referring to a single version
at the foundation (and perhaps with a single local cached copy for
disconnected installations). We should have these discussions early so
that a new set of rules is in place long before the next crazy phase...
<br>
<blockquote type="cite"><br>
The costs (on committers, largely) and benefits (commercial members)
are not equitable IMHO. I understand the benefit to commercial
members, but like I said I think the costs and benefits are not
equitably distributed.
<br>
</blockquote>
We discussed this issue yesterday as well. Working for IBM, I know
there is a great deal of value in providing an IP clean result that can
be consumed by commercial vendors. But I can see that the burden for
making this happen is extremely onerous to the committer community,
many of whom get little or no direct benefit from this. I'm also
concerned that the battle of the open source licenses (LGPL is bad?)
will affect our community in an adverse way. Sure it's a great thing
that Eclipse builds components that can be used in anywhere, even for
commercial products, but should there be rules that dictate that this
is the only thing it should do, i.e., it should never provide
integration with any LGPL library because LGPL is so inherently bad
that we should build a giant firewall to keep it from tainting our
perfectly pure and good EPL code? I would hope not (because otherwise
Teneo could not provide integration with Hibernate).
<br>
<blockquote type="cite"><br>
2) The lack of company diversity on projects. I still think this is a
particularly insidious problem for the Board and committers...one which
I don't think the strategics or the add-on providers will do anything
about until pushed by the committers/committer reps.
<br>
</blockquote>
I'll just climb on my soap box and point out that the modeling project
is a model of diversity and wait for people to contradict me. :-) I
think project diversity is likely a problem specific to each project
and you can't simply tell people to be more diverse and expect it will
happen. I can certainly relate to why people might be concerned about
diversifying their projects. There are lots of fly-by-night people in
this world, and to have code dumped and them left behind is not
something any of us want to handle. All that being said, I think
diversity has great value and we should take steps to make it happen;
it's certainly been a topic of board conversations already. And not to
point any fingers, but starting with the platform as the model of
perfection the rest of ascribe to, would be a good place. We need to
ask ourselves why it is that the platform committer base has not
diversified? I don't think it's purely an issue of people being kept
out. I think many people are more than happy to take a free ride with
occasional fits of wanting to dump their half baked solutions into the
mix. (Feel free to contradict me!)
<br>
<blockquote type="cite"><br>
3) The 'project as technical silos' problem. Although related to 2,
it's not the same. Even if projects had representatives from multiple
companies they still might not be cooperating/collaborating across
projects. Especially with Europa, it's becoming clear to me that there
is a lot of duplication of effort/code/work across multiple projects
(e.g. ECF and DSDP and others all doing service discovery stuff, etc).
I don't think this is healthy for the committers in the long term.
<br>
</blockquote>
I totally agree. I think part of the problem is that many projects
create one big silo, so if you want a little bag of grain, you need to
haul in the 18 wheeler and take on a full load. Smaller features like
what we did for EMF recently would help. But features really suck and
maintaining them is going to be kind of a nightmare. Perhaps the new
provisioning story will be at least partially a panacea (and doesn't
end up delivering "features" with a new word to label them).
<br>
<blockquote type="cite"><br>
4) The lack of membership support for volunteer projects. Does the EF
membership want only corporate run projects? If so, is this a healthy
environment for committers in terms of innovation and interest?
<br>
</blockquote>
I don't believe the foundation wants only corporate run projects. But
keep in mind that the dominance of corporate interests at Eclipse is
perhaps significantly driven by the apathy of those with alternative
points of view (and perhaps by the poor job the committer reps do
representing these alternative points of view). You being a notable
exception of course. :-) IBM for one contributes huge sums of money by
funding a large number of committers, so it's understandable that it
will expect its interests to be well served by this large investment.
But many of us also use large portions of our own personal time to make
Eclipse great and I personally work hard to encourage a diverse
community within EMF/EMFT and the modeling project that includes
individuals, smaller companies, and academics. It's up to each of us
to help balance the scales. And we shouldn't be too quick to overlook
the extent to which corporate interests helps facilitate and fund the
great community we are building.
<br>
<blockquote type="cite"><br>
5) Lack of follow-thru of strategic members on membership requirements
WRT people commitment. Each strategic member is required provide a
minimum of 8 committers (See Exhibit B in membership agreement:
<a class="moz-txt-link-freetext" href=" http://www.eclipse.org/org/documents/Eclipse%20MEMBERSHIP%20 AGMT%202007_04_04%20Final.pdf"> http://www.eclipse.org/org/documents/Eclipse%20MEMBERSHIP%20 AGMT%202007_04_04%20Final.pdf</a>).
I'm pretty sure that a good number of the current strategics are not
meeting this requirement (even in name only), and I think the result is
greater burden on the strategics that are, and a greater burden on
smaller orgs and independents.
<br>
</blockquote>
Hopefully some of those folks are reading this and will feel sheepish.
Just as it was time to review every license file we ship (because we'd
all agreed to follow the not-so-clear rules), I think it's time to
review the commitments the strategic members are living up to or not.
It's always unpleasant to embarrass people though. :-(
<br>
<blockquote type="cite"><br>
I suppose that's enough from me for now. I expect/hope that others
have input about what the committers should be discussing at the
upcoming Board meeting...and hopefully they will have the time to
discuss some of their plans in this regard publicly before the actual
meeting.
<br>
</blockquote>
Unfortunately I don't think we are so terribly well organized yet.
Right now is an incredibly busy time for us "real developers". It's
reassuring though that all the issues you've brought up in this note
have been points of discussion already...
<br>
<blockquote type="cite"><br>
Thanks to Chris, Jeff, Konstantin, Ed, and Darin for representing the
community.
<br>
<br>
Scott
<br>
</blockquote>
</blockquote>
</blockquote>
<br>
</body>
</html>
--------------080201060509090002060501--
|
|
|
| Re: Board Meeting [message #6026 is a reply to message #5287] |
Thu, 28 June 2007 17:55 |
| Eclipse User |
|
|
|
Originally posted by: slewis.composent.com
Hi Ed,
Thanks for the terrific report (and thanks to Chris for posting the blog
entry also).
A couple of comments interspersed.
Ed Merks wrote:
> Scott,
>
> Sure, set me up to publicly break board confidentiality. :-) There
> were discussions at the meeting about confidentiality but I think most
> of us are still not very comfortable with where the dividing line is.
> It's clearly inappropriate to talk about "he said this" and "she said
> that" though. Such information should come only from the published
> minutes after the board has voted to approve the publication of those
> minutes. I'm hopeful that minutes will be published more promptly,
> i.e., within four weeks of the meeting, so that will help a bit.
>
> IP discussions where certainly a dominant theme at this board meeting,
> both as a committer rep issue and as an issue brought to the board at
> the plenary session by the planning council. We'd all like to see
> things run more smoothly with less delays and it looks like additional
> staff is in the works; we're applying pressure for still more. :-)
I think this could be a double-edged sword. What I mean by this is that
I would certainly like to see the (overworked) EF legal folks have
additional resources, but I don't know if it can scale. That is, it
would be easy to imagine the EF growing to be mostly people to help with
the IP process, and I don't know if that's what committers really want.
> Parallel IP is very popular, and many of us would like to see it applied
> more broadly. As such, we are taking further steps to investigate how
> that can be enabled without compromising the integrity and confidence
> folks have that when they download something from Eclipse, their legal
> concerns are nonexistent. So expect to hear more on this front in the
> coming months.
Yes...although I think that the parallel IP process is a very good
thing, I think it creates a number of tough problems...e.g. the
limitation to projects in incubation...in practice, most projects have
*pieces* of themselves that are mature, and pieces that are immature/in
incubation...and obviously the IP process should be applied differently.
Otherwise we end up with Equinox project, Equinox incubator project,
EMF project EMF incubator project, ECF project, ECF incubator project, etc.
>We've also committed to work more closely with Janet and
> her IP team to help improve the current processes and to define new ones
> so as to ensure more of an element of predictability to the handling of
> IP reviews and to have less redundancy in the legal files that are
> distributed.
I think this is good. No reason for this to be adversarial.
It's a big challenge for such a small team and under the
> circumstances, they are doing the best they can with the resources
> available to accomplish the foundation's goals.
Yes, I know this is true. My comment though is that it's the Board's
responsibility to set reasonable and workable goals.
An interesting thing to
> keep in mind is that while a developer is comfortable saying something
> will take a week and have it end up taking three weeks, legal folks feel
> more like their word is a legal contract. ;-)
Even more than the "Eclipse Way: deliver on time" contract? :). I'm
just kidding around...I actually like a more rigorous 'word is a legal
contract' approach. I try to approach that in my own commitments as
much as possible.
>
> There were long discussions about changes to the IP policy to deal with
> what are characterized as "depends-on" verses "works-with"
> dependencies. There were a great number of concerns with the initial
> wording, so we had a fun time doing committee wordsmithing to end up
> with a result I think everyone was comfortable with. I had specific
> concerns with regard to Teneo's use of Hibernate in this regard. It's
> important to the foundation that projects generally provide deliverables
> that are effectively full function without a requirement for the
> installation of components with a license incompatible with EPL (since
> that leaves most commercial vendors in a bind). It think the board has
> done a good job balancing this need against the desire to also provide
> integration with well-established popular LGPL software.
I've just had a chance to look at the guidelines. Without further
context, they seem reasonable to me. But I think the thing to avoid is
putting all the enforcement on manual processes for the project
teams/committers. That is, if there are ways *by process* or by
technology to limit the amount of policing work then those are the
things that need resources...e.g. people to do work on tools/tools
improvements, etc., etc.
>
> Project diversity is definitely a concern for many but it's clear that
> you can't simply require diversity and expect it to happen. Among the
> things that are needed are things each project could help do. I.e.,
> clear instructions of how to set up an image from CVS (a team project
> set) so that patches can be produced, and clear instructions for how to
> set up and run the JUnits so that patches are sound and so that new
> JUnits to test them are provided. The platform team is committed to
> helping move in the right direction, but each project is in excellent
> position to help with that. I understand that VE is attracting some new
> committers; it's an example where lack of diversity has clearly hurt not
> only that project but Eclipse as a whole by virtue of affecting how well
> rounded its offerings are...
I happen to believe that what's needed is to create an environment where
diversity is expected (rather than required). What does this mean?
Well, I think that having participation rules that allow diversity would
be good, I also think that if IP compliance requirements can be put on
project leads/PMC then certainly they can seek out diversity (which
requires them to look outside of their organization for people
*interested* in working on the project).
But I know this is a hard issue, especially given the way things are now.
>
> The committer reps talked about the project silo issues and there was
> some talk about a "commons" project, but not all of us were comfortable
> with that idea. I think the fundamental problem is that the boxes
> themselves set up boundaries so creating new boxes does not solve the
> boundaries problem.
True, setting up new boundaries (projects) does not inherently solve the
problem, but I do think that it depends upon what the character of the
project is. So a commons project may be a good idea, if it is
setup/executed right (i.e. to make it easy for committers to use,
prevents them from wasting time reimplementing a common piece of
functionality, etc).
In my opinion, only finer grained builds and
> distributions will help truly bring the barriers down.
This is something that will help, IMHO. See the
provisioning/install/update work. But I don't think that mechanism
alone is the total answer.
Within the
> modeling space, we have a very large number of small components, so we
> are learning to manage the build infrastructure to support this and we
> are more than happy to share the results with the rest of the
> community. Nick has done amazing things for us and we can now get new
> components started rapidly. For example, check out how cool our search
> CVS facility is.
>
> http://www.eclipse.org/modeling/emf/searchcvs.php?q=194088
>
> All that's required is to include [<bugzilla-number>] in the CVS commit
> comment, and you get automatic release notes published with each build
> along with the ability to see the CVS delta for each and every one in
> your web browser.
This sounds great. Speaking with my ECF hat, we would *love* to have
access to all of the work that Nick and others have done WRT the
EMF/EMFT builds. It's tricky, though, because the requirements on
builds vary so widely, and it is currently very hard to get started with
building.
>
> In terms of volunteer projects, that's kind of difficult issue. You
> can't really force people to volunteer, or they wouldn't be
> volunteering. :-)
I don't think it's a matter of forcing people to volunteer. The
interesting thing about the technical community, I think, is that if you
are doing something interesting/useful, and out in the open, people will
volunteer. But you have to make it *possible* for volunteers to
participate...because their terms are different:
1) they can't spend full time working on anything
2) they need to have barriers to entry lower (i.e. easier to participate
in a non-'prime mover' way)
3) they need to be able to keep up with what's going on with the project
without seeing/being with/blogging with the community every day
4) the work has to be interesting to them (i.e. I doubt that good
technical people will volunteer to help with some things).
But I'm hopeful that the foundation will eventually
> have a bit more money to staff the building of infrastructure that
> supports the common good.
Yes, I agree.
As committers, there's an awful lot we can do
> ourselves in this regard.
Yes, I agree.
>
> And finally, I did raise the issue of strategic member commitments and
> I'm hopeful that in the not-to-distant future the web page that lists
> all the strategic members will include an up-to-date list of the people
> that each member has committed towards full time work at Eclipse. We
> have a few privacy issues to tackle before we can put that in place.
Sounds like a good idea. Thanks for raising it Ed...I know it's
sensitive, but it does seem to me that if we're going to have that
commitment that it makes sense to make it real.
>
> Overall I was *extremely *happy with how the board meetings went. The
> board is populated by a very constructive group of people who work well
> together. They are very responsive to committer issues so any
> perception that committer issues take a back seat are definitely unfounded.
For the record, I also think that the Board is a good group, and
sensitive/responsive to committer issues. I didn't mean to imply
otherwise. But realistically, the interests of the various groups on
the Board (committers, strategics, add-in providers, EF, etc) do *not*
overlap completely...and that means that where they differ (e.g.
importance of tech innovation, importance of community and
collaboration, resource allocation, sustainability of community) it's
important that all committer's interests are well represented.
I don't mean to be pedantic...as I know you all probably agree with the
above...but I think it's worth saying occasionally.
>
> Was there anything else specifically you wanted to hear more about?
No, thanks. I would like to talk some face-to-face when we have a
chance, but nothing more right now.
Thanks again for representation and the information flow.
Scott
>
>
> Scott Lewis wrote:
>> Now that Europa is nearly in the can :), any public comments from the
>> Committer Board reps about the Board meeting last week?
>>
>> Scott
>>
>>
>> Ed Merks wrote:
>>> Scott,
>>>
>>> Thanks. I must confess that so far I think I've been doing a pretty
>>> poor job of being a committer rep. I've been too busy with all my
>>> own (EMF) issues to pay enough attention to the community's issues.
>>> As a group, we are now planning to have a call with Bjorn before each
>>> board meeting to discuss the issues that need attention at the next
>>> board meeting. More comments below...
>>>
>>>
>>> Scott Lewis wrote:
>>>> Committer Reps,
>>>>
>>>> I understand there is a Board meeting coming up next week (June 18)
>>>> and I want to start a dialog here about what committer issues may be
>>>> brought up/discussed before the Board.
>>> Good idea.
>>>>
>>>> Since the squeaky wheel gets the attention :)...as a committer, here
>>>> are my 'pet peeves' for the Board:
>>> Yes. Speak now or you forfeit the right to complain later. (I
>>> haven't forgotten your issue about needing incubating projects to use
>>> parallel IP.)
>>>>
>>>> 1) The IP process...for Europa and beyond. I continually have the
>>>> impression that all the work of the IP process falls on two groups:
>>>>
>>>> a) the foundation personnel (from outside it seems that more and
>>>> more foundation dollars are likely going to feed that monster) and I
>>>> don't see how that scales as Ganymede is even bigger than Europa.
>>> Yesterday we did discuss with Bjorn the lack of resource to handle IP
>>> reviews fast enough. We are all pinched by this and as the IP
>>> demands increase, this problem will only get worse. So personally,
>>> before the board decides to make any more decisions that will
>>> increase the IP burden of the foundation staff, I'd like to be sure
>>> that the funding for that burden is significantly increased.
>>>>
>>>> b) the committers (who do the work associated with adding license
>>>> files, about files, etc. etc.).
>>> It was incredibly frustrating to have this license file debacle take
>>> place at precisely the worst possible time for the committers who
>>> needed to contain it. In the future, the rules should be much more
>>> clear, and we should be addressing it early in the cycle, not during
>>> the crazy shutdown phase. Even the rules themselves are highly
>>> questionable. Having 1,000 copies of the license.html as well as the
>>> 1,000 copies within the properties files is just not a sensible way
>>> to distribute a common and consistent license; translating these
>>> files to multiple languages makes the problem even worse. So we'd
>>> like to discuss how to make this more sensible by referring to a
>>> single version at the foundation (and perhaps with a single local
>>> cached copy for disconnected installations). We should have these
>>> discussions early so that a new set of rules is in place long before
>>> the next crazy phase...
>>>>
>>>> The costs (on committers, largely) and benefits (commercial members)
>>>> are not equitable IMHO. I understand the benefit to commercial
>>>> members, but like I said I think the costs and benefits are not
>>>> equitably distributed.
>>> We discussed this issue yesterday as well. Working for IBM, I know
>>> there is a great deal of value in providing an IP clean result that
>>> can be consumed by commercial vendors. But I can see that the burden
>>> for making this happen is extremely onerous to the committer
>>> community, many of whom get little or no direct benefit from this.
>>> I'm also concerned that the battle of the open source licenses (LGPL
>>> is bad?) will affect our community in an adverse way. Sure it's a
>>> great thing that Eclipse builds components that can be used in
>>> anywhere, even for commercial products, but should there be rules
>>> that dictate that this is the only thing it should do, i.e., it
>>> should never provide integration with any LGPL library because LGPL
>>> is so inherently bad that we should build a giant firewall to keep it
>>> from tainting our perfectly pure and good EPL code? I would hope not
>>> (because otherwise Teneo could not provide integration with Hibernate).
>>>>
>>>> 2) The lack of company diversity on projects. I still think this is
>>>> a particularly insidious problem for the Board and committers...one
>>>> which I don't think the strategics or the add-on providers will do
>>>> anything about until pushed by the committers/committer reps.
>>> I'll just climb on my soap box and point out that the modeling
>>> project is a model of diversity and wait for people to contradict
>>> me. :-) I think project diversity is likely a problem specific to
>>> each project and you can't simply tell people to be more diverse and
>>> expect it will happen. I can certainly relate to why people might be
>>> concerned about diversifying their projects. There are lots of
>>> fly-by-night people in this world, and to have code dumped and them
>>> left behind is not something any of us want to handle. All that
>>> being said, I think diversity has great value and we should take
>>> steps to make it happen; it's certainly been a topic of board
>>> conversations already. And not to point any fingers, but starting
>>> with the platform as the model of perfection the rest of ascribe to,
>>> would be a good place. We need to ask ourselves why it is that the
>>> platform committer base has not diversified? I don't think it's
>>> purely an issue of people being kept out. I think many people are
>>> more than happy to take a free ride with occasional fits of wanting
>>> to dump their half baked solutions into the mix. (Feel free to
>>> contradict me!)
>>>>
>>>> 3) The 'project as technical silos' problem. Although related to 2,
>>>> it's not the same. Even if projects had representatives from
>>>> multiple companies they still might not be cooperating/collaborating
>>>> across projects. Especially with Europa, it's becoming clear to me
>>>> that there is a lot of duplication of effort/code/work across
>>>> multiple projects (e.g. ECF and DSDP and others all doing service
>>>> discovery stuff, etc). I don't think this is healthy for the
>>>> committers in the long term.
>>> I totally agree. I think part of the problem is that many projects
>>> create one big silo, so if you want a little bag of grain, you need
>>> to haul in the 18 wheeler and take on a full load. Smaller features
>>> like what we did for EMF recently would help. But features really
>>> suck and maintaining them is going to be kind of a nightmare.
>>> Perhaps the new provisioning story will be at least partially a
>>> panacea (and doesn't end up delivering "features" with a new word to
>>> label them).
>>>>
>>>> 4) The lack of membership support for volunteer projects. Does the
>>>> EF membership want only corporate run projects? If so, is this a
>>>> healthy environment for committers in terms of innovation and interest?
>>> I don't believe the foundation wants only corporate run projects.
>>> But keep in mind that the dominance of corporate interests at Eclipse
>>> is perhaps significantly driven by the apathy of those with
>>> alternative points of view (and perhaps by the poor job the committer
>>> reps do representing these alternative points of view). You being a
>>> notable exception of course. :-) IBM for one contributes huge sums
>>> of money by funding a large number of committers, so it's
>>> understandable that it will expect its interests to be well served by
>>> this large investment. But many of us also use large portions of our
>>> own personal time to make Eclipse great and I personally work hard to
>>> encourage a diverse community within EMF/EMFT and the modeling
>>> project that includes individuals, smaller companies, and academics.
>>> It's up to each of us to help balance the scales. And we shouldn't
>>> be too quick to overlook the extent to which corporate interests
>>> helps facilitate and fund the great community we are building.
>>>>
>>>> 5) Lack of follow-thru of strategic members on membership
>>>> requirements WRT people commitment. Each strategic member is
>>>> required provide a minimum of 8 committers (See Exhibit B in
>>>> membership agreement:
>>>> http://www.eclipse.org/org/documents/Eclipse%20MEMBERSHIP%20 AGMT%202007_04_04%20Final.pdf).
>>>> I'm pretty sure that a good number of the current strategics are
>>>> not meeting this requirement (even in name only), and I think the
>>>> result is greater burden on the strategics that are, and a greater
>>>> burden on smaller orgs and independents.
>>> Hopefully some of those folks are reading this and will feel
>>> sheepish. Just as it was time to review every license file we ship
>>> (because we'd all agreed to follow the not-so-clear rules), I think
>>> it's time to review the commitments the strategic members are living
>>> up to or not. It's always unpleasant to embarrass people though. :-(
>>>>
>>>> I suppose that's enough from me for now. I expect/hope that others
>>>> have input about what the committers should be discussing at the
>>>> upcoming Board meeting...and hopefully they will have the time to
>>>> discuss some of their plans in this regard publicly before the
>>>> actual meeting.
>>> Unfortunately I don't think we are so terribly well organized yet.
>>> Right now is an incredibly busy time for us "real developers". It's
>>> reassuring though that all the issues you've brought up in this note
>>> have been points of discussion already...
>>>>
>>>> Thanks to Chris, Jeff, Konstantin, Ed, and Darin for representing
>>>> the community.
>>>>
>>>> Scott
>
|
|
|
| Re: Board Meeting [message #560379 is a reply to message #5010] |
Wed, 13 June 2007 12:11 |
 Ed Merks
Messages: 33252
Registered: July 2009 |
Senior Member |
|
|
Scott,
Thanks. I must confess that so far I think I've been doing a pretty
poor job of being a committer rep. I've been too busy with all my own
(EMF) issues to pay enough attention to the community's issues. As a
group, we are now planning to have a call with Bjorn before each board
meeting to discuss the issues that need attention at the next board
meeting. More comments below...
Scott Lewis wrote:
> Committer Reps,
>
> I understand there is a Board meeting coming up next week (June 18)
> and I want to start a dialog here about what committer issues may be
> brought up/discussed before the Board.
Good idea.
>
> Since the squeaky wheel gets the attention :)...as a committer, here
> are my 'pet peeves' for the Board:
Yes. Speak now or you forfeit the right to complain later. (I haven't
forgotten your issue about needing incubating projects to use parallel IP.)
>
> 1) The IP process...for Europa and beyond. I continually have the
> impression that all the work of the IP process falls on two groups:
>
> a) the foundation personnel (from outside it seems that more and more
> foundation dollars are likely going to feed that monster) and I don't
> see how that scales as Ganymede is even bigger than Europa.
Yesterday we did discuss with Bjorn the lack of resource to handle IP
reviews fast enough. We are all pinched by this and as the IP demands
increase, this problem will only get worse. So personally, before the
board decides to make any more decisions that will increase the IP
burden of the foundation staff, I'd like to be sure that the funding for
that burden is significantly increased.
>
> b) the committers (who do the work associated with adding license
> files, about files, etc. etc.).
It was incredibly frustrating to have this license file debacle take
place at precisely the worst possible time for the committers who needed
to contain it. In the future, the rules should be much more clear, and
we should be addressing it early in the cycle, not during the crazy
shutdown phase. Even the rules themselves are highly questionable.
Having 1,000 copies of the license.html as well as the 1,000 copies
within the properties files is just not a sensible way to distribute a
common and consistent license; translating these files to multiple
languages makes the problem even worse. So we'd like to discuss how to
make this more sensible by referring to a single version at the
foundation (and perhaps with a single local cached copy for disconnected
installations). We should have these discussions early so that a new
set of rules is in place long before the next crazy phase...
>
> The costs (on committers, largely) and benefits (commercial members)
> are not equitable IMHO. I understand the benefit to commercial
> members, but like I said I think the costs and benefits are not
> equitably distributed.
We discussed this issue yesterday as well. Working for IBM, I know there
is a great deal of value in providing an IP clean result that can be
consumed by commercial vendors. But I can see that the burden for
making this happen is extremely onerous to the committer community, many
of whom get little or no direct benefit from this. I'm also concerned
that the battle of the open source licenses (LGPL is bad?) will affect
our community in an adverse way. Sure it's a great thing that Eclipse
builds components that can be used in anywhere, even for commercial
products, but should there be rules that dictate that this is the only
thing it should do, i.e., it should never provide integration with any
LGPL library because LGPL is so inherently bad that we should build a
giant firewall to keep it from tainting our perfectly pure and good EPL
code? I would hope not (because otherwise Teneo could not provide
integration with Hibernate).
>
> 2) The lack of company diversity on projects. I still think this is a
> particularly insidious problem for the Board and committers...one
> which I don't think the strategics or the add-on providers will do
> anything about until pushed by the committers/committer reps.
I'll just climb on my soap box and point out that the modeling project
is a model of diversity and wait for people to contradict me. :-) I
think project diversity is likely a problem specific to each project and
you can't simply tell people to be more diverse and expect it will
happen. I can certainly relate to why people might be concerned about
diversifying their projects. There are lots of fly-by-night people in
this world, and to have code dumped and them left behind is not
something any of us want to handle. All that being said, I think
diversity has great value and we should take steps to make it happen;
it's certainly been a topic of board conversations already. And not to
point any fingers, but starting with the platform as the model of
perfection the rest of ascribe to, would be a good place. We need to
ask ourselves why it is that the platform committer base has not
diversified? I don't think it's purely an issue of people being kept
out. I think many people are more than happy to take a free ride with
occasional fits of wanting to dump their half baked solutions into the
mix. (Feel free to contradict me!)
>
> 3) The 'project as technical silos' problem. Although related to 2,
> it's not the same. Even if projects had representatives from multiple
> companies they still might not be cooperating/collaborating across
> projects. Especially with Europa, it's becoming clear to me that
> there is a lot of duplication of effort/code/work across multiple
> projects (e.g. ECF and DSDP and others all doing service discovery
> stuff, etc). I don't think this is healthy for the committers in the
> long term.
I totally agree. I think part of the problem is that many projects
create one big silo, so if you want a little bag of grain, you need to
haul in the 18 wheeler and take on a full load. Smaller features like
what we did for EMF recently would help. But features really suck and
maintaining them is going to be kind of a nightmare. Perhaps the new
provisioning story will be at least partially a panacea (and doesn't end
up delivering "features" with a new word to label them).
>
> 4) The lack of membership support for volunteer projects. Does the EF
> membership want only corporate run projects? If so, is this a healthy
> environment for committers in terms of innovation and interest?
I don't believe the foundation wants only corporate run projects. But
keep in mind that the dominance of corporate interests at Eclipse is
perhaps significantly driven by the apathy of those with alternative
points of view (and perhaps by the poor job the committer reps do
representing these alternative points of view). You being a notable
exception of course. :-) IBM for one contributes huge sums of money by
funding a large number of committers, so it's understandable that it
will expect its interests to be well served by this large investment.
But many of us also use large portions of our own personal time to make
Eclipse great and I personally work hard to encourage a diverse
community within EMF/EMFT and the modeling project that includes
individuals, smaller companies, and academics. It's up to each of us to
help balance the scales. And we shouldn't be too quick to overlook the
extent to which corporate interests helps facilitate and fund the great
community we are building.
>
> 5) Lack of follow-thru of strategic members on membership requirements
> WRT people commitment. Each strategic member is required provide a
> minimum of 8 committers (See Exhibit B in membership agreement:
> http://www.eclipse.org/org/documents/Eclipse%20MEMBERSHIP%20 AGMT%202007_04_04%20Final.pdf).
> I'm pretty sure that a good number of the current strategics are not
> meeting this requirement (even in name only), and I think the result
> is greater burden on the strategics that are, and a greater burden on
> smaller orgs and independents.
Hopefully some of those folks are reading this and will feel sheepish.
Just as it was time to review every license file we ship (because we'd
all agreed to follow the not-so-clear rules), I think it's time to
review the commitments the strategic members are living up to or not.
It's always unpleasant to embarrass people though. :-(
>
> I suppose that's enough from me for now. I expect/hope that others
> have input about what the committers should be discussing at the
> upcoming Board meeting...and hopefully they will have the time to
> discuss some of their plans in this regard publicly before the actual
> meeting.
Unfortunately I don't think we are so terribly well organized yet.
Right now is an incredibly busy time for us "real developers". It's
reassuring though that all the issues you've brought up in this note
have been points of discussion already...
>
> Thanks to Chris, Jeff, Konstantin, Ed, and Darin for representing the
> community.
>
> Scott
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Board Meeting [message #560385 is a reply to message #5080] |
Wed, 13 June 2007 16:53 |
Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Ed,
Thanks for the thoughtful response...a couple of minor comments below.
Ed Merks wrote:
> Scott,
>
> Thanks. I must confess that so far I think I've been doing a pretty
> poor job of being a committer rep. I've been too busy with all my own
> (EMF) issues to pay enough attention to the community's issues. As a
> group, we are now planning to have a call with Bjorn before each board
> meeting to discuss the issues that need attention at the next board
> meeting. More comments below...
>
>
> Scott Lewis wrote:
>> Committer Reps,
>>
>> I understand there is a Board meeting coming up next week (June 18)
>> and I want to start a dialog here about what committer issues may be
>> brought up/discussed before the Board.
> Good idea.
>>
>> Since the squeaky wheel gets the attention :)...as a committer, here
>> are my 'pet peeves' for the Board:
> Yes. Speak now or you forfeit the right to complain later. (I haven't
> forgotten your issue about needing incubating projects to use parallel IP.)
>>
>> 1) The IP process...for Europa and beyond. I continually have the
>> impression that all the work of the IP process falls on two groups:
>>
>> a) the foundation personnel (from outside it seems that more and more
>> foundation dollars are likely going to feed that monster) and I don't
>> see how that scales as Ganymede is even bigger than Europa.
> Yesterday we did discuss with Bjorn the lack of resource to handle IP
> reviews fast enough. We are all pinched by this and as the IP demands
> increase, this problem will only get worse. So personally, before the
> board decides to make any more decisions that will increase the IP
> burden of the foundation staff, I'd like to be sure that the funding for
> that burden is significantly increased.
>>
>> b) the committers (who do the work associated with adding license
>> files, about files, etc. etc.).
> It was incredibly frustrating to have this license file debacle take
> place at precisely the worst possible time for the committers who needed
> to contain it. In the future, the rules should be much more clear, and
> we should be addressing it early in the cycle, not during the crazy
> shutdown phase. Even the rules themselves are highly questionable.
> Having 1,000 copies of the license.html as well as the 1,000 copies
> within the properties files is just not a sensible way to distribute a
> common and consistent license; translating these files to multiple
> languages makes the problem even worse. So we'd like to discuss how to
> make this more sensible by referring to a single version at the
> foundation (and perhaps with a single local cached copy for disconnected
> installations). We should have these discussions early so that a new
> set of rules is in place long before the next crazy phase...
I agree.
>>
>> The costs (on committers, largely) and benefits (commercial members)
>> are not equitable IMHO. I understand the benefit to commercial
>> members, but like I said I think the costs and benefits are not
>> equitably distributed.
> We discussed this issue yesterday as well. Working for IBM, I know there
> is a great deal of value in providing an IP clean result that can be
> consumed by commercial vendors. But I can see that the burden for
> making this happen is extremely onerous to the committer community, many
> of whom get little or no direct benefit from this. I'm also concerned
> that the battle of the open source licenses (LGPL is bad?) will affect
> our community in an adverse way. Sure it's a great thing that Eclipse
> builds components that can be used in anywhere, even for commercial
> products, but should there be rules that dictate that this is the only
> thing it should do, i.e., it should never provide integration with any
> LGPL library because LGPL is so inherently bad that we should build a
> giant firewall to keep it from tainting our perfectly pure and good EPL
> code? I would hope not (because otherwise Teneo could not provide
> integration with Hibernate).
Note I'm personally not as concerned with the restrictions on using
alternative licenses, but I do believe it is a hinderance in some cases
(it has been for my project anyway)...so I do believe it's a significant
issue for committers as well. It holds back innovation because a lot of
innovation takes place in LGPL, GPL and other lands...
>>
>> 2) The lack of company diversity on projects. I still think this is a
>> particularly insidious problem for the Board and committers...one
>> which I don't think the strategics or the add-on providers will do
>> anything about until pushed by the committers/committer reps.
> I'll just climb on my soap box and point out that the modeling project
> is a model of diversity and wait for people to contradict me. :-) I
> think project diversity is likely a problem specific to each project and
> you can't simply tell people to be more diverse and expect it will
> happen. I can certainly relate to why people might be concerned about
> diversifying their projects. There are lots of fly-by-night people in
> this world, and to have code dumped and them left behind is not
> something any of us want to handle. All that being said, I think
> diversity has great value and we should take steps to make it happen;
> it's certainly been a topic of board conversations already. And not to
> point any fingers, but starting with the platform as the model of
> perfection the rest of ascribe to, would be a good place. We need to
> ask ourselves why it is that the platform committer base has not
> diversified? I don't think it's purely an issue of people being kept
> out. I think many people are more than happy to take a free ride with
> occasional fits of wanting to dump their half baked solutions into the
> mix. (Feel free to contradict me!)
I think when the issue is framed as quality vs. project diversity it's
a misrepresentation. I would be the last to suggest that quality of EF
projects should be reduced. But I don't think (as some seem to) that
project diversity necessarily will result in lower quality. Just
because the Platform is of very high quality and it is not very diverse
doesn't mean that project diversity implies lower quality. I think
that's a conflation.
I think the committers as a group should suggest some more
approaches/ideas to maintaining quality while increasing project
diversity. I think the dev process changes approved in january are a
great start (e.g. mentors for projects, etc). Perhaps some peer review
(i.e. committers outside a given project being asked to
use/comment/review APIs, docs, etc).
>>
>> 3) The 'project as technical silos' problem. Although related to 2,
>> it's not the same. Even if projects had representatives from multiple
>> companies they still might not be cooperating/collaborating across
>> projects. Especially with Europa, it's becoming clear to me that
>> there is a lot of duplication of effort/code/work across multiple
>> projects (e.g. ECF and DSDP and others all doing service discovery
>> stuff, etc). I don't think this is healthy for the committers in the
>> long term.
> I totally agree. I think part of the problem is that many projects
> create one big silo, so if you want a little bag of grain, you need to
> haul in the 18 wheeler and take on a full load. Smaller features like
> what we did for EMF recently would help. But features really suck and
> maintaining them is going to be kind of a nightmare. Perhaps the new
> provisioning story will be at least partially a panacea (and doesn't end
> up delivering "features" with a new word to label them).
I didn't mean to impune EMF, Platform or any other project in this
regard...I think the collaboration/cross-project issue is a big and
general one for all foundation projects. But very important for
committer interests like innovation, user satisfaction with all EF
projects and community, etc.
>>
>> 4) The lack of membership support for volunteer projects. Does the EF
>> membership want only corporate run projects? If so, is this a healthy
>> environment for committers in terms of innovation and interest?
> I don't believe the foundation wants only corporate run projects. But
> keep in mind that the dominance of corporate interests at Eclipse is
> perhaps significantly driven by the apathy of those with alternative
> points of view (and perhaps by the poor job the committer reps do
> representing these alternative points of view). You being a notable
> exception of course. :-) IBM for one contributes huge sums of money by
> funding a large number of committers, so it's understandable that it
> will expect its interests to be well served by this large investment.
> But many of us also use large portions of our own personal time to make
> Eclipse great and I personally work hard to encourage a diverse
> community within EMF/EMFT and the modeling project that includes
> individuals, smaller companies, and academics. It's up to each of us to
> help balance the scales. And we shouldn't be too quick to overlook the
> extent to which corporate interests helps facilitate and fund the great
> community we are building.
I don't think I'm overlooking it. I value it highly as well. But I
feel that although money is an important enabler (of course), it doesn't
explain the commitment, dedication, and ownership that comes with the
'founder' role...and in the EF I consider the committers akin to the
'founders' of an organization.
I think the committers, through their 'sweat equity' show a commitment
and dedication that demands more than 'you've been paid for your time,
so we'll take it from here'. Here's a little thought experiment: would
you be working on Eclipse technology even if <your company> didn't exist
and you weren't paid for it? That is, is
Eclipse/WTP/EMF/ECF/DSDP/Corona your avocation as well as your vocation?
I would guess that for many committers (and contributor) the anwswer
would be 'yes'. Independent and voluntary committers are just an
'extreme' form of this demonstrated commitment...as they are dedicated
enough (or perhaps foolish enough :) to work on something they believe
in/like/understand/enjoy/get creative and personal value from, even if
it doesn't provide them with any obvious ROI. I think this is the
laudable insight behind having committer representatives on the Board at
all (how many sw companies have representatives on their Boards for
engineers?).
So anyway, my point is not that the money isn't important...not at all.
...and I don't even mean to minimize it's important. But my point is
that funding alone doesn't imply *total* ownership of the value and
community created by Eclipse. There is a lot of personal creativity and
commitment that is required above and beyond the money...and I think
those contributions imply some respect as well.
Reminds me of Jim Clark (Netscape) famous saying:
"In a ham and egg breakfast, the pig is committed, and the chicken is
not" :)
>>
>> 5) Lack of follow-thru of strategic members on membership requirements
>> WRT people commitment. Each strategic member is required provide a
>> minimum of 8 committers (See Exhibit B in membership agreement:
>> http://www.eclipse.org/org/documents/Eclipse%20MEMBERSHIP%20 AGMT%202007_04_04%20Final.pdf).
>> I'm pretty sure that a good number of the current strategics are not
>> meeting this requirement (even in name only), and I think the result
>> is greater burden on the strategics that are, and a greater burden on
>> smaller orgs and independents.
> Hopefully some of those folks are reading this and will feel sheepish.
> Just as it was time to review every license file we ship (because we'd
> all agreed to follow the not-so-clear rules), I think it's time to
> review the commitments the strategic members are living up to or not.
> It's always unpleasant to embarrass people though. :-(
Not my intention...and I don't want to get any of you 'in trouble'
around this issue. But the 'free rider' problem is important though, I
believe, because I think the committers (and the strategics that are
meeting/exceeding this commitment) are both being implicitly taken
advantage of...and I think this can reduce the sustainability of the
entire community (or at least puts it at greater risk).
>>
>> I suppose that's enough from me for now. I expect/hope that others
>> have input about what the committers should be discussing at the
>> upcoming Board meeting...and hopefully they will have the time to
>> discuss some of their plans in this regard publicly before the actual
>> meeting.
> Unfortunately I don't think we are so terribly well organized yet.
> Right now is an incredibly busy time for us "real developers". It's
> reassuring though that all the issues you've brought up in this note
> have been points of discussion already...
That's good. I don't wish to be an irritant to any/all of the committer
reps...just to help in the connection between all committers and the Board.
Scott
|
|
|
| Re: Board Meeting [message #560391 is a reply to message #5080] |
Wed, 27 June 2007 21:51 |
Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Now that Europa is nearly in the can :), any public comments from the
Committer Board reps about the Board meeting last week?
Scott
Ed Merks wrote:
> Scott,
>
> Thanks. I must confess that so far I think I've been doing a pretty
> poor job of being a committer rep. I've been too busy with all my own
> (EMF) issues to pay enough attention to the community's issues. As a
> group, we are now planning to have a call with Bjorn before each board
> meeting to discuss the issues that need attention at the next board
> meeting. More comments below...
>
>
> Scott Lewis wrote:
>> Committer Reps,
>>
>> I understand there is a Board meeting coming up next week (June 18)
>> and I want to start a dialog here about what committer issues may be
>> brought up/discussed before the Board.
> Good idea.
>>
>> Since the squeaky wheel gets the attention :)...as a committer, here
>> are my 'pet peeves' for the Board:
> Yes. Speak now or you forfeit the right to complain later. (I haven't
> forgotten your issue about needing incubating projects to use parallel IP.)
>>
>> 1) The IP process...for Europa and beyond. I continually have the
>> impression that all the work of the IP process falls on two groups:
>>
>> a) the foundation personnel (from outside it seems that more and more
>> foundation dollars are likely going to feed that monster) and I don't
>> see how that scales as Ganymede is even bigger than Europa.
> Yesterday we did discuss with Bjorn the lack of resource to handle IP
> reviews fast enough. We are all pinched by this and as the IP demands
> increase, this problem will only get worse. So personally, before the
> board decides to make any more decisions that will increase the IP
> burden of the foundation staff, I'd like to be sure that the funding for
> that burden is significantly increased.
>>
>> b) the committers (who do the work associated with adding license
>> files, about files, etc. etc.).
> It was incredibly frustrating to have this license file debacle take
> place at precisely the worst possible time for the committers who needed
> to contain it. In the future, the rules should be much more clear, and
> we should be addressing it early in the cycle, not during the crazy
> shutdown phase. Even the rules themselves are highly questionable.
> Having 1,000 copies of the license.html as well as the 1,000 copies
> within the properties files is just not a sensible way to distribute a
> common and consistent license; translating these files to multiple
> languages makes the problem even worse. So we'd like to discuss how to
> make this more sensible by referring to a single version at the
> foundation (and perhaps with a single local cached copy for disconnected
> installations). We should have these discussions early so that a new
> set of rules is in place long before the next crazy phase...
>>
>> The costs (on committers, largely) and benefits (commercial members)
>> are not equitable IMHO. I understand the benefit to commercial
>> members, but like I said I think the costs and benefits are not
>> equitably distributed.
> We discussed this issue yesterday as well. Working for IBM, I know there
> is a great deal of value in providing an IP clean result that can be
> consumed by commercial vendors. But I can see that the burden for
> making this happen is extremely onerous to the committer community, many
> of whom get little or no direct benefit from this. I'm also concerned
> that the battle of the open source licenses (LGPL is bad?) will affect
> our community in an adverse way. Sure it's a great thing that Eclipse
> builds components that can be used in anywhere, even for commercial
> products, but should there be rules that dictate that this is the only
> thing it should do, i.e., it should never provide integration with any
> LGPL library because LGPL is so inherently bad that we should build a
> giant firewall to keep it from tainting our perfectly pure and good EPL
> code? I would hope not (because otherwise Teneo could not provide
> integration with Hibernate).
>>
>> 2) The lack of company diversity on projects. I still think this is a
>> particularly insidious problem for the Board and committers...one
>> which I don't think the strategics or the add-on providers will do
>> anything about until pushed by the committers/committer reps.
> I'll just climb on my soap box and point out that the modeling project
> is a model of diversity and wait for people to contradict me. :-) I
> think project diversity is likely a problem specific to each project and
> you can't simply tell people to be more diverse and expect it will
> happen. I can certainly relate to why people might be concerned about
> diversifying their projects. There are lots of fly-by-night people in
> this world, and to have code dumped and them left behind is not
> something any of us want to handle. All that being said, I think
> diversity has great value and we should take steps to make it happen;
> it's certainly been a topic of board conversations already. And not to
> point any fingers, but starting with the platform as the model of
> perfection the rest of ascribe to, would be a good place. We need to
> ask ourselves why it is that the platform committer base has not
> diversified? I don't think it's purely an issue of people being kept
> out. I think many people are more than happy to take a free ride with
> occasional fits of wanting to dump their half baked solutions into the
> mix. (Feel free to contradict me!)
>>
>> 3) The 'project as technical silos' problem. Although related to 2,
>> it's not the same. Even if projects had representatives from multiple
>> companies they still might not be cooperating/collaborating across
>> projects. Especially with Europa, it's becoming clear to me that
>> there is a lot of duplication of effort/code/work across multiple
>> projects (e.g. ECF and DSDP and others all doing service discovery
>> stuff, etc). I don't think this is healthy for the committers in the
>> long term.
> I totally agree. I think part of the problem is that many projects
> create one big silo, so if you want a little bag of grain, you need to
> haul in the 18 wheeler and take on a full load. Smaller features like
> what we did for EMF recently would help. But features really suck and
> maintaining them is going to be kind of a nightmare. Perhaps the new
> provisioning story will be at least partially a panacea (and doesn't end
> up delivering "features" with a new word to label them).
>>
>> 4) The lack of membership support for volunteer projects. Does the EF
>> membership want only corporate run projects? If so, is this a healthy
>> environment for committers in terms of innovation and interest?
> I don't believe the foundation wants only corporate run projects. But
> keep in mind that the dominance of corporate interests at Eclipse is
> perhaps significantly driven by the apathy of those with alternative
> points of view (and perhaps by the poor job the committer reps do
> representing these alternative points of view). You being a notable
> exception of course. :-) IBM for one contributes huge sums of money by
> funding a large number of committers, so it's understandable that it
> will expect its interests to be well served by this large investment.
> But many of us also use large portions of our own personal time to make
> Eclipse great and I personally work hard to encourage a diverse
> community within EMF/EMFT and the modeling project that includes
> individuals, smaller companies, and academics. It's up to each of us to
> help balance the scales. And we shouldn't be too quick to overlook the
> extent to which corporate interests helps facilitate and fund the great
> community we are building.
>>
>> 5) Lack of follow-thru of strategic members on membership requirements
>> WRT people commitment. Each strategic member is required provide a
>> minimum of 8 committers (See Exhibit B in membership agreement:
>> http://www.eclipse.org/org/documents/Eclipse%20MEMBERSHIP%20 AGMT%202007_04_04%20Final.pdf).
>> I'm pretty sure that a good number of the current strategics are not
>> meeting this requirement (even in name only), and I think the result
>> is greater burden on the strategics that are, and a greater burden on
>> smaller orgs and independents.
> Hopefully some of those folks are reading this and will feel sheepish.
> Just as it was time to review every license file we ship (because we'd
> all agreed to follow the not-so-clear rules), I think it's time to
> review the commitments the strategic members are living up to or not.
> It's always unpleasant to embarrass people though. :-(
>>
>> I suppose that's enough from me for now. I expect/hope that others
>> have input about what the committers should be discussing at the
>> upcoming Board meeting...and hopefully they will have the time to
>> discuss some of their plans in this regard publicly before the actual
>> meeting.
> Unfortunately I don't think we are so terribly well organized yet.
> Right now is an incredibly busy time for us "real developers". It's
> reassuring though that all the issues you've brought up in this note
> have been points of discussion already...
>>
>> Thanks to Chris, Jeff, Konstantin, Ed, and Darin for representing the
>> community.
>>
>> Scott
|
|
|
| Re: Board Meeting [message #560397 is a reply to message #5216] |
Thu, 28 June 2007 12:00 |
Ed Merks
Messages: 33252
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------080201060509090002060501
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Scott,
Sure, set me up to publicly break board confidentiality. :-) There
were discussions at the meeting about confidentiality but I think most
of us are still not very comfortable with where the dividing line is.
It's clearly inappropriate to talk about "he said this" and "she said
that" though. Such information should come only from the published
minutes after the board has voted to approve the publication of those
minutes. I'm hopeful that minutes will be published more promptly,
i.e., within four weeks of the meeting, so that will help a bit.
IP discussions where certainly a dominant theme at this board meeting,
both as a committer rep issue and as an issue brought to the board at
the plenary session by the planning council. We'd all like to see
things run more smoothly with less delays and it looks like additional
staff is in the works; we're applying pressure for still more. :-)
Parallel IP is very popular, and many of us would like to see it applied
more broadly. As such, we are taking further steps to investigate how
that can be enabled without compromising the integrity and confidence
folks have that when they download something from Eclipse, their legal
concerns are nonexistent. So expect to hear more on this front in the
coming months. We've also committed to work more closely with Janet and
her IP team to help improve the current processes and to define new ones
so as to ensure more of an element of predictability to the handling of
IP reviews and to have less redundancy in the legal files that are
distributed. It's a big challenge for such a small team and under the
circumstances, they are doing the best they can with the resources
available to accomplish the foundation's goals. An interesting thing to
keep in mind is that while a developer is comfortable saying something
will take a week and have it end up taking three weeks, legal folks feel
more like their word is a legal contract. ;-)
There were long discussions about changes to the IP policy to deal with
what are characterized as "depends-on" verses "works-with"
dependencies. There were a great number of concerns with the initial
wording, so we had a fun time doing committee wordsmithing to end up
with a result I think everyone was comfortable with. I had specific
concerns with regard to Teneo's use of Hibernate in this regard. It's
important to the foundation that projects generally provide deliverables
that are effectively full function without a requirement for the
installation of components with a license incompatible with EPL (since
that leaves most commercial vendors in a bind). It think the board has
done a good job balancing this need against the desire to also provide
integration with well-established popular LGPL software.
Project diversity is definitely a concern for many but it's clear that
you can't simply require diversity and expect it to happen. Among the
things that are needed are things each project could help do. I.e.,
clear instructions of how to set up an image from CVS (a team project
set) so that patches can be produced, and clear instructions for how to
set up and run the JUnits so that patches are sound and so that new
JUnits to test them are provided. The platform team is committed to
helping move in the right direction, but each project is in excellent
position to help with that. I understand that VE is attracting some new
committers; it's an example where lack of diversity has clearly hurt not
only that project but Eclipse as a whole by virtue of affecting how well
rounded its offerings are...
The committer reps talked about the project silo issues and there was
some talk about a "commons" project, but not all of us were comfortable
with that idea. I think the fundamental problem is that the boxes
themselves set up boundaries so creating new boxes does not solve the
boundaries problem. In my opinion, only finer grained builds and
distributions will help truly bring the barriers down. Within the
modeling space, we have a very large number of small components, so we
are learning to manage the build infrastructure to support this and we
are more than happy to share the results with the rest of the
community. Nick has done amazing things for us and we can now get new
components started rapidly. For example, check out how cool our search
CVS facility is.
http://www.eclipse.org/modeling/emf/searchcvs.php?q=194088
All that's required is to include [<bugzilla-number>] in the CVS commit
comment, and you get automatic release notes published with each build
along with the ability to see the CVS delta for each and every one in
your web browser.
In terms of volunteer projects, that's kind of difficult issue. You
can't really force people to volunteer, or they wouldn't be
volunteering. :-) But I'm hopeful that the foundation will eventually
have a bit more money to staff the building of infrastructure that
supports the common good. As committers, there's an awful lot we can do
ourselves in this regard.
And finally, I did raise the issue of strategic member commitments and
I'm hopeful that in the not-to-distant future the web page that lists
all the strategic members will include an up-to-date list of the people
that each member has committed towards full time work at Eclipse. We
have a few privacy issues to tackle before we can put that in place.
Overall I was *extremely *happy with how the board meetings went. The
board is populated by a very constructive group of people who work well
together. They are very responsive to committer issues so any
perception that committer issues take a back seat are definitely unfounded.
Was there anything else specifically you wanted to hear more about?
Scott Lewis wrote:
> Now that Europa is nearly in the can :), any public comments from the
> Committer Board reps about the Board meeting last week?
>
> Scott
>
>
> Ed Merks wrote:
>> Scott,
>>
>> Thanks. I must confess that so far I think I've been doing a pretty
>> poor job of being a committer rep. I've been too busy with all my
>> own (EMF) issues to pay enough attention to the community's issues.
>> As a group, we are now planning to have a call with Bjorn before each
>> board meeting to discuss the issues that need attention at the next
>> board meeting. More comments below...
>>
>>
>> Scott Lewis wrote:
>>> Committer Reps,
>>>
>>> I understand there is a Board meeting coming up next week (June 18)
>>> and I want to start a dialog here about what committer issues may be
>>> brought up/discussed before the Board.
>> Good idea.
>>>
>>> Since the squeaky wheel gets the attention :)...as a committer, here
>>> are my 'pet peeves' for the Board:
>> Yes. Speak now or you forfeit the right to complain later. (I
>> haven't forgotten your issue about needing incubating projects to use
>> parallel IP.)
>>>
>>> 1) The IP process...for Europa and beyond. I continually have the
>>> impression that all the work of the IP process falls on two groups:
>>>
>>> a) the foundation personnel (from outside it seems that more and
>>> more foundation dollars are likely going to feed that monster) and I
>>> don't see how that scales as Ganymede is even bigger than Europa.
>> Yesterday we did discuss with Bjorn the lack of resource to handle IP
>> reviews fast enough. We are all pinched by this and as the IP
>> demands increase, this problem will only get worse. So personally,
>> before the board decides to make any more decisions that will
>> increase the IP burden of the foundation staff, I'd like to be sure
>> that the funding for that burden is significantly increased.
>>>
>>> b) the committers (who do the work associated with adding license
>>> files, about files, etc. etc.).
>> It was incredibly frustrating to have this license file debacle take
>> place at precisely the worst possible time for the committers who
>> needed to contain it. In the future, the rules should be much more
>> clear, and we should be addressing it early in the cycle, not during
>> the crazy shutdown phase. Even the rules themselves are highly
>> questionable. Having 1,000 copies of the license.html as well as the
>> 1,000 copies within the properties files is just not a sensible way
>> to distribute a common and consistent license; translating these
>> files to multiple languages makes the problem even worse. So we'd
>> like to discuss how to make this more sensible by referring to a
>> single version at the foundation (and perhaps with a single local
>> cached copy for disconnected installations). We should have these
>> discussions early so that a new set of rules is in place long before
>> the next crazy phase...
>>>
>>> The costs (on committers, largely) and benefits (commercial members)
>>> are not equitable IMHO. I understand the benefit to commercial
>>> members, but like I said I think the costs and benefits are not
>>> equitably distributed.
>> We discussed this issue yesterday as well. Working for IBM, I know
>> there is a great deal of value in providing an IP clean result that
>> can be consumed by commercial vendors. But I can see that the burden
>> for making this happen is extremely onerous to the committer
>> community, many of whom get little or no direct benefit from this.
>> I'm also concerned that the battle of the open source licenses (LGPL
>> is bad?) will affect our community in an adverse way. Sure it's a
>> great thing that Eclipse builds components that can be used in
>> anywhere, even for commercial products, but should there be rules
>> that dictate that this is the only thing it should do, i.e., it
>> should never provide integration with any LGPL library because LGPL
>> is so inherently bad that we should build a giant firewall to keep it
>> from tainting our perfectly pure and good EPL code? I would hope not
>> (because otherwise Teneo could not provide integration with Hibernate).
>>>
>>> 2) The lack of company diversity on projects. I still think this is
>>> a particularly insidious problem for the Board and committers...one
>>> which I don't think the strategics or the add-on providers will do
>>> anything about until pushed by the committers/committer reps.
>> I'll just climb on my soap box and point out that the modeling
>> project is a model of diversity and wait for people to contradict
>> me. :-) I think project diversity is likely a problem specific to
>> each project and you can't simply tell people to be more diverse and
>> expect it will happen. I can certainly relate to why people might be
>> concerned about diversifying their projects. There are lots of
>> fly-by-night people in this world, and to have code dumped and them
>> left behind is not something any of us want to handle. All that
>> being said, I think diversity has great value and we should take
>> steps to make it happen; it's certainly been a topic of board
>> conversations already. And not to point any fingers, but starting
>> with the platform as the model of perfection the rest of ascribe to,
>> would be a good place. We need to ask ourselves why it is that the
>> platform committer base has not diversified? I don't think it's
>> purely an issue of people being kept out. I think many people are
>> more than happy to take a free ride with occasional fits of wanting
>> to dump their half baked solutions into the mix. (Feel free to
>> contradict me!)
>>>
>>> 3) The 'project as technical silos' problem. Although related to 2,
>>> it's not the same. Even if projects had representatives from
>>> multiple companies they still might not be cooperating/collaborating
>>> across projects. Especially with Europa, it's becoming clear to me
>>> that there is a lot of duplication of effort/code/work across
>>> multiple projects (e.g. ECF and DSDP and others all doing service
>>> discovery stuff, etc). I don't think this is healthy for the
>>> committers in the long term.
>> I totally agree. I think part of the problem is that many projects
>> create one big silo, so if you want a little bag of grain, you need
>> to haul in the 18 wheeler and take on a full load. Smaller features
>> like what we did for EMF recently would help. But features really
>> suck and maintaining them is going to be kind of a nightmare.
>> Perhaps the new provisioning story will be at least partially a
>> panacea (and doesn't end up delivering "features" with a new word to
>> label them).
>>>
>>> 4) The lack of membership support for volunteer projects. Does the
>>> EF membership want only corporate run projects? If so, is this a
>>> healthy environment for committers in terms of innovation and interest?
>> I don't believe the foundation wants only corporate run projects.
>> But keep in mind that the dominance of corporate interests at Eclipse
>> is perhaps significantly driven by the apathy of those with
>> alternative points of view (and perhaps by the poor job the committer
>> reps do representing these alternative points of view). You being a
>> notable exception of course. :-) IBM for one contributes huge sums
>> of money by funding a large number of committers, so it's
>> understandable that it will expect its interests to be well served by
>> this large investment. But many of us also use large portions of our
>> own personal time to make Eclipse great and I personally work hard to
>> encourage a diverse community within EMF/EMFT and the modeling
>> project that includes individuals, smaller companies, and academics.
>> It's up to each of us to help balance the scales. And we shouldn't
>> be too quick to overlook the extent to which corporate interests
>> helps facilitate and fund the great community we are building.
>>>
>>> 5) Lack of follow-thru of strategic members on membership
>>> requirements WRT people commitment. Each strategic member is
>>> required provide a minimum of 8 committers (See Exhibit B in
>>> membership agreement:
>>> http://www.eclipse.org/org/documents/Eclipse%20MEMBERSHIP%20 AGMT%202007_04_04%20Final.pdf).
>>> I'm pretty sure that a good number of the current strategics are
>>> not meeting this requirement (even in name only), and I think the
>>> result is greater burden on the strategics that are, and a greater
>>> burden on smaller orgs and independents.
>> Hopefully some of those folks are reading this and will feel
>> sheepish. Just as it was time to review every license file we ship
>> (because we'd all agreed to follow the not-so-clear rules), I think
>> it's time to review the commitments the strategic members are living
>> up to or not. It's always unpleasant to embarrass people though. :-(
>>>
>>> I suppose that's enough from me for now. I expect/hope that others
>>> have input about what the committers should be discussing at the
>>> upcoming Board meeting...and hopefully they will have the time to
>>> discuss some of their plans in this regard publicly before the
>>> actual meeting.
>> Unfortunately I don't think we are so terribly well organized yet.
>> Right now is an incredibly busy time for us "real developers". It's
>> reassuring though that all the issues you've brought up in this note
>> have been points of discussion already...
>>>
>>> Thanks to Chris, Jeff, Konstantin, Ed, and Darin for representing
>>> the community.
>>>
>>> Scott
--------------080201060509090002060501
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Scott,<br>
<br>
Sure, set me up to publicly break board confidentiality. :-) There
were discussions at the meeting about confidentiality but I think most
of us are still not very comfortable with where the dividing line is.
It's clearly inappropriate to talk about "he said this" and "she said
that" though. Such information should come only from the published
minutes after the board has voted to approve the publication of those
minutes. I'm hopeful that minutes will be published more promptly,
i.e., within four weeks of the meeting, so that will help a bit.<br>
<br>
IP discussions where certainly a dominant theme at this board meeting,
both as a committer rep issue and as an issue brought to the board at
the plenary session by the planning council. We'd all like to see
things run more smoothly with less delays and it looks like additional
staff is in the works; we're applying pressure for still more. :-)
Parallel IP is very popular, and many of us would like to see it
applied more broadly. As such, we are taking further steps to
investigate how that can be enabled without compromising the integrity
and confidence folks have that when they download something from
Eclipse, their legal concerns are nonexistent. So expect to hear more
on this front in the coming months. We've also committed to work more
closely with Janet and her IP team to help improve the current
processes and to define new ones so as to ensure more of an element of
predictability to the handling of IP reviews and to have less
redundancy in the legal files that are distributed. It's a big
challenge for such a small team and under the circumstances, they are
doing the best they can with the resources available to accomplish the
foundation's goals. An interesting thing to keep in mind is that while
a developer is comfortable saying something will take a week and have
it end up taking three weeks, legal folks feel more like their word is
a legal contract. ;-)<br>
<br>
There were long discussions about changes to the IP policy to deal with
what are characterized as "depends-on" verses "works-with"
dependencies. There were a great number of concerns with the initial
wording, so we had a fun time doing committee wordsmithing to end up
with a result I think everyone was comfortable with. I had specific
concerns with regard to Teneo's use of Hibernate in this regard. It's
important to the foundation that projects generally provide
deliverables that are effectively full function without a requirement
for the installation of components with a license incompatible with EPL
(since that leaves most commercial vendors in a bind). It think the
board has done a good job balancing this need against the desire to
also provide integration with well-established popular LGPL software.<br>
<br>
Project diversity is definitely a concern for many but it's clear that
you can't simply require diversity and expect it to happen. Among the
things that are needed are things each project could help do. I.e.,
clear instructions of how to set up an image from CVS (a team project
set) so that patches can be produced, and clear instructions for how to
set up and run the JUnits so that patches are sound and so that new
JUnits to test them are provided. The platform team is committed to
helping move in the right direction, but each project is in excellent
position to help with that. I understand that VE is attracting some
new committers; it's an example where lack of diversity has clearly
hurt not only that project but Eclipse as a whole by virtue of
affecting how well rounded its offerings are...<br>
<br>
The committer reps talked about the project silo issues and there was
some talk about a "commons" project, but not all of us were comfortable
with that idea. I think the fundamental problem is that the boxes
themselves set up boundaries so creating new boxes does not solve the
boundaries problem. In my opinion, only finer grained builds and
distributions will help truly bring the barriers down. Within the
modeling space, we have a very large number of small components, so we
are learning to manage the build infrastructure to support this and we
are more than happy to share the results with the rest of the
community. Nick has done amazing things for us and we can now get new
components started rapidly. For example, check out how cool our search
CVS facility is. <br>
<blockquote><a
href="http://www.eclipse.org/modeling/emf/searchcvs.php?q=194088">http://www.eclipse.org/modeling/emf/searchcvs.php?q=194088</a><br>
</blockquote>
All that's required is to include [<bugzilla-number>] in the CVS
commit comment, and you get automatic release notes published with each
build along with the ability to see the CVS delta for each and every
one in your web browser.<br>
<br>
In terms of volunteer projects, that's kind of difficult issue. You
can't really force people to volunteer, or they wouldn't be
volunteering. :-) But I'm hopeful that the foundation will
eventually have a bit more money to staff the building of
infrastructure that supports the common good. As committers, there's
an awful lot we can do ourselves in this regard.<br>
<br>
And finally, I did raise the issue of strategic member commitments and
I'm hopeful that in the not-to-distant future the web page that lists
all the strategic members will include an up-to-date list of the people
that each member has committed towards full time work at Eclipse. We
have a few privacy issues to tackle before we can put that in place.<br>
<br>
Overall I was <b>extremely </b>happy with how the board meetings
went. The
board is populated by a very constructive group of people who work well
together. They are very responsive to committer issues so any
perception that committer issues take a back seat are definitely
unfounded.<br>
<br>
Was there anything else specifically you wanted to hear more about?<br>
<br>
<br>
Scott Lewis wrote:
<blockquote cite="mid:f5um5r$1ki$1@build.eclipse.org" type="cite">Now
that Europa is nearly in the can :), any public comments from the
Committer Board reps about the Board meeting last week?
<br>
<br>
Scott
<br>
<br>
<br>
Ed Merks wrote:
<br>
<blockquote type="cite">Scott,
<br>
<br>
Thanks. I must confess that so far I think I've been doing a pretty
poor job of being a committer rep. I've been too busy with all my own
(EMF) issues to pay enough attention to the community's issues. As a
group, we are now planning to have a call with Bjorn before each board
meeting to discuss the issues that need attention at the next board
meeting. More comments below...
<br>
<br>
<br>
Scott Lewis wrote:
<br>
<blockquote type="cite">Committer Reps,
<br>
<br>
I understand there is a Board meeting coming up next week (June 18) and
I want to start a dialog here about what committer issues may be
brought up/discussed before the Board.
<br>
</blockquote>
Good idea.
<br>
<blockquote type="cite"><br>
Since the squeaky wheel gets the attention :)...as a committer, here
are my 'pet peeves' for the Board:
<br>
</blockquote>
Yes. Speak now or you forfeit the right to complain later. (I haven't
forgotten your issue about needing incubating projects to use parallel
IP.)
<br>
<blockquote type="cite"><br>
1) The IP process...for Europa and beyond. I continually have the
impression that all the work of the IP process falls on two groups:
<br>
<br>
a) the foundation personnel (from outside it seems that more and more
foundation dollars are likely going to feed that monster) and I don't
see how that scales as Ganymede is even bigger than Europa.
<br>
</blockquote>
Yesterday we did discuss with Bjorn the lack of resource to handle IP
reviews fast enough. We are all pinched by this and as the IP demands
increase, this problem will only get worse. So personally, before the
board decides to make any more decisions that will increase the IP
burden of the foundation staff, I'd like to be sure that the funding
for that burden is significantly increased.
<br>
<blockquote type="cite"><br>
b) the committers (who do the work associated with adding license
files, about files, etc. etc.).
<br>
</blockquote>
It was incredibly frustrating to have this license file debacle take
place at precisely the worst possible time for the committers who
needed to contain it. In the future, the rules should be much more
clear, and we should be addressing it early in the cycle, not during
the crazy shutdown phase. Even the rules themselves are highly
questionable. Having 1,000 copies of the license.html as well as the
1,000 copies within the properties files is just not a sensible way to
distribute a common and consistent license; translating these files to
multiple languages makes the problem even worse. So we'd like to
discuss how to make this more sensible by referring to a single version
at the foundation (and perhaps with a single local cached copy for
disconnected installations). We should have these discussions early so
that a new set of rules is in place long before the next crazy phase...
<br>
<blockquote type="cite"><br>
The costs (on committers, largely) and benefits (commercial members)
are not equitable IMHO. I understand the benefit to commercial
members, but like I said I think the costs and benefits are not
equitably distributed.
<br>
</blockquote>
We discussed this issue yesterday as well. Working for IBM, I know
there is a great deal of value in providing an IP clean result that can
be consumed by commercial vendors. But I can see that the burden for
making this happen is extremely onerous to the committer community,
many of whom get little or no direct benefit from this. I'm also
concerned that the battle of the open source licenses (LGPL is bad?)
will affect our community in an adverse way. Sure it's a great thing
that Eclipse builds components that can be used in anywhere, even for
commercial products, but should there be rules that dictate that this
is the only thing it should do, i.e., it should never provide
integration with any LGPL library because LGPL is so inherently bad
that we should build a giant firewall to keep it from tainting our
perfectly pure and good EPL code? I would hope not (because otherwise
Teneo could not provide integration with Hibernate).
<br>
<blockquote type="cite"><br>
2) The lack of company diversity on projects. I still think this is a
particularly insidious problem for the Board and committers...one which
I don't think the strategics or the add-on providers will do anything
about until pushed by the committers/committer reps.
<br>
</blockquote>
I'll just climb on my soap box and point out that the modeling project
is a model of diversity and wait for people to contradict me. :-) I
think project diversity is likely a problem specific to each project
and you can't simply tell people to be more diverse and expect it will
happen. I can certainly relate to why people might be concerned about
diversifying their projects. There are lots of fly-by-night people in
this world, and to have code dumped and them left behind is not
something any of us want to handle. All that being said, I think
diversity has great value and we should take steps to make it happen;
it's certainly been a topic of board conversations already. And not to
point any fingers, but starting with the platform as the model of
perfection the rest of ascribe to, would be a good place. We need to
ask ourselves why it is that the platform committer base has not
diversified? I don't think it's purely an issue of people being kept
out. I think many people are more than happy to take a free ride with
occasional fits of wanting to dump their half baked solutions into the
mix. (Feel free to contradict me!)
<br>
<blockquote type="cite"><br>
3) The 'project as technical silos' problem. Although related to 2,
it's not the same. Even if projects had representatives from multiple
companies they still might not be cooperating/collaborating across
projects. Especially with Europa, it's becoming clear to me that there
is a lot of duplication of effort/code/work across multiple projects
(e.g. ECF and DSDP and others all doing service discovery stuff, etc).
I don't think this is healthy for the committers in the long term.
<br>
</blockquote>
I totally agree. I think part of the problem is that many projects
create one big silo, so if you want a little bag of grain, you need to
haul in the 18 wheeler and take on a full load. Smaller features like
what we did for EMF recently would help. But features really suck and
maintaining them is going to be kind of a nightmare. Perhaps the new
provisioning story will be at least partially a panacea (and doesn't
end up delivering "features" with a new word to label them).
<br>
<blockquote type="cite"><br>
4) The lack of membership support for volunteer projects. Does the EF
membership want only corporate run projects? If so, is this a healthy
environment for committers in terms of innovation and interest?
<br>
</blockquote>
I don't believe the foundation wants only corporate run projects. But
keep in mind that the dominance of corporate interests at Eclipse is
perhaps significantly driven by the apathy of those with alternative
points of view (and perhaps by the poor job the committer reps do
representing these alternative points of view). You being a notable
exception of course. :-) IBM for one contributes huge sums of money by
funding a large number of committers, so it's understandable that it
will expect its interests to be well served by this large investment.
But many of us also use large portions of our own personal time to make
Eclipse great and I personally work hard to encourage a diverse
community within EMF/EMFT and the modeling project that includes
individuals, smaller companies, and academics. It's up to each of us
to help balance the scales. And we shouldn't be too quick to overlook
the extent to which corporate interests helps facilitate and fund the
great community we are building.
<br>
<blockquote type="cite"><br>
5) Lack of follow-thru of strategic members on membership requirements
WRT people commitment. Each strategic member is required provide a
minimum of 8 committers (See Exhibit B in membership agreement:
<a class="moz-txt-link-freetext" href=" http://www.eclipse.org/org/documents/Eclipse%20MEMBERSHIP%20 AGMT%202007_04_04%20Final.pdf"> http://www.eclipse.org/org/documents/Eclipse%20MEMBERSHIP%20 AGMT%202007_04_04%20Final.pdf</a>).
I'm pretty sure that a good number of the current strategics are not
meeting this requirement (even in name only), and I think the result is
greater burden on the strategics that are, and a greater burden on
smaller orgs and independents.
<br>
</blockquote>
Hopefully some of those folks are reading this and will feel sheepish.
Just as it was time to review every license file we ship (because we'd
all agreed to follow the not-so-clear rules), I think it's time to
review the commitments the strategic members are living up to or not.
It's always unpleasant to embarrass people though. :-(
<br>
<blockquote type="cite"><br>
I suppose that's enough from me for now. I expect/hope that others
have input about what the committers should be discussing at the
upcoming Board meeting...and hopefully they will have the time to
discuss some of their plans in this regard publicly before the actual
meeting.
<br>
</blockquote>
Unfortunately I don't think we are so terribly well organized yet.
Right now is an incredibly busy time for us "real developers". It's
reassuring though that all the issues you've brought up in this note
have been points of discussion already...
<br>
<blockquote type="cite"><br>
Thanks to Chris, Jeff, Konstantin, Ed, and Darin for representing the
community.
<br>
<br>
Scott
<br>
</blockquote>
</blockquote>
</blockquote>
<br>
</body>
</html>
--------------080201060509090002060501--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Board Meeting [message #560409 is a reply to message #5287] |
Thu, 28 June 2007 17:55 |
Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Ed,
Thanks for the terrific report (and thanks to Chris for posting the blog
entry also).
A couple of comments interspersed.
Ed Merks wrote:
> Scott,
>
> Sure, set me up to publicly break board confidentiality. :-) There
> were discussions at the meeting about confidentiality but I think most
> of us are still not very comfortable with where the dividing line is.
> It's clearly inappropriate to talk about "he said this" and "she said
> that" though. Such information should come only from the published
> minutes after the board has voted to approve the publication of those
> minutes. I'm hopeful that minutes will be published more promptly,
> i.e., within four weeks of the meeting, so that will help a bit.
>
> IP discussions where certainly a dominant theme at this board meeting,
> both as a committer rep issue and as an issue brought to the board at
> the plenary session by the planning council. We'd all like to see
> things run more smoothly with less delays and it looks like additional
> staff is in the works; we're applying pressure for still more. :-)
I think this could be a double-edged sword. What I mean by this is that
I would certainly like to see the (overworked) EF legal folks have
additional resources, but I don't know if it can scale. That is, it
would be easy to imagine the EF growing to be mostly people to help with
the IP process, and I don't know if that's what committers really want.
> Parallel IP is very popular, and many of us would like to see it applied
> more broadly. As such, we are taking further steps to investigate how
> that can be enabled without compromising the integrity and confidence
> folks have that when they download something from Eclipse, their legal
> concerns are nonexistent. So expect to hear more on this front in the
> coming months.
Yes...although I think that the parallel IP process is a very good
thing, I think it creates a number of tough problems...e.g. the
limitation to projects in incubation...in practice, most projects have
*pieces* of themselves that are mature, and pieces that are immature/in
incubation...and obviously the IP process should be applied differently.
Otherwise we end up with Equinox project, Equinox incubator project,
EMF project EMF incubator project, ECF project, ECF incubator project, etc.
>We've also committed to work more closely with Janet and
> her IP team to help improve the current processes and to define new ones
> so as to ensure more of an element of predictability to the handling of
> IP reviews and to have less redundancy in the legal files that are
> distributed.
I think this is good. No reason for this to be adversarial.
It's a big challenge for such a small team and under the
> circumstances, they are doing the best they can with the resources
> available to accomplish the foundation's goals.
Yes, I know this is true. My comment though is that it's the Board's
responsibility to set reasonable and workable goals.
An interesting thing to
> keep in mind is that while a developer is comfortable saying something
> will take a week and have it end up taking three weeks, legal folks feel
> more like their word is a legal contract. ;-)
Even more than the "Eclipse Way: deliver on time" contract? :). I'm
just kidding around...I actually like a more rigorous 'word is a legal
contract' approach. I try to approach that in my own commitments as
much as possible.
>
> There were long discussions about changes to the IP policy to deal with
> what are characterized as "depends-on" verses "works-with"
> dependencies. There were a great number of concerns with the initial
> wording, so we had a fun time doing committee wordsmithing to end up
> with a result I think everyone was comfortable with. I had specific
> concerns with regard to Teneo's use of Hibernate in this regard. It's
> important to the foundation that projects generally provide deliverables
> that are effectively full function without a requirement for the
> installation of components with a license incompatible with EPL (since
> that leaves most commercial vendors in a bind). It think the board has
> done a good job balancing this need against the desire to also provide
> integration with well-established popular LGPL software.
I've just had a chance to look at the guidelines. Without further
context, they seem reasonable to me. But I think the thing to avoid is
putting all the enforcement on manual processes for the project
teams/committers. That is, if there are ways *by process* or by
technology to limit the amount of policing work then those are the
things that need resources...e.g. people to do work on tools/tools
improvements, etc., etc.
>
> Project diversity is definitely a concern for many but it's clear that
> you can't simply require diversity and expect it to happen. Among the
> things that are needed are things each project could help do. I.e.,
> clear instructions of how to set up an image from CVS (a team project
> set) so that patches can be produced, and clear instructions for how to
> set up and run the JUnits so that patches are sound and so that new
> JUnits to test them are provided. The platform team is committed to
> helping move in the right direction, but each project is in excellent
> position to help with that. I understand that VE is attracting some new
> committers; it's an example where lack of diversity has clearly hurt not
> only that project but Eclipse as a whole by virtue of affecting how well
> rounded its offerings are...
I happen to believe that what's needed is to create an environment where
diversity is expected (rather than required). What does this mean?
Well, I think that having participation rules that allow diversity would
be good, I also think that if IP compliance requirements can be put on
project leads/PMC then certainly they can seek out diversity (which
requires them to look outside of their organization for people
*interested* in working on the project).
But I know this is a hard issue, especially given the way things are now.
>
> The committer reps talked about the project silo issues and there was
> some talk about a "commons" project, but not all of us were comfortable
> with that idea. I think the fundamental problem is that the boxes
> themselves set up boundaries so creating new boxes does not solve the
> boundaries problem.
True, setting up new boundaries (projects) does not inherently solve the
problem, but I do think that it depends upon what the character of the
project is. So a commons project may be a good idea, if it is
setup/executed right (i.e. to make it easy for committers to use,
prevents them from wasting time reimplementing a common piece of
functionality, etc).
In my opinion, only finer grained builds and
> distributions will help truly bring the barriers down.
This is something that will help, IMHO. See the
provisioning/install/update work. But I don't think that mechanism
alone is the total answer.
Within the
> modeling space, we have a very large number of small components, so we
> are learning to manage the build infrastructure to support this and we
> are more than happy to share the results with the rest of the
> community. Nick has done amazing things for us and we can now get new
> components started rapidly. For example, check out how cool our search
> CVS facility is.
>
> http://www.eclipse.org/modeling/emf/searchcvs.php?q=194088
>
> All that's required is to include [<bugzilla-number>] in the CVS commit
> comment, and you get automatic release notes published with each build
> along with the ability to see the CVS delta for each and every one in
> your web browser.
This sounds great. Speaking with my ECF hat, we would *love* to have
access to all of the work that Nick and others have done WRT the
EMF/EMFT builds. It's tricky, though, because the requirements on
builds vary so widely, and it is currently very hard to get started with
building.
>
> In terms of volunteer projects, that's kind of difficult issue. You
> can't really force people to volunteer, or they wouldn't be
> volunteering. :-)
I don't think it's a matter of forcing people to volunteer. The
interesting thing about the technical community, I think, is that if you
are doing something interesting/useful, and out in the open, people will
volunteer. But you have to make it *possible* for volunteers to
participate...because their terms are different:
1) they can't spend full time working on anything
2) they need to have barriers to entry lower (i.e. easier to participate
in a non-'prime mover' way)
3) they need to be able to keep up with what's going on with the project
without seeing/being with/blogging with the community every day
4) the work has to be interesting to them (i.e. I doubt that good
technical people will volunteer to help with some things).
But I'm hopeful that the foundation will eventually
> have a bit more money to staff the building of infrastructure that
> supports the common good.
Yes, I agree.
As committers, there's an awful lot we can do
> ourselves in this regard.
Yes, I agree.
>
> And finally, I did raise the issue of strategic member commitments and
> I'm hopeful that in the not-to-distant future the web page that lists
> all the strategic members will include an up-to-date list of the people
> that each member has committed towards full time work at Eclipse. We
> have a few privacy issues to tackle before we can put that in place.
Sounds like a good idea. Thanks for raising it Ed...I know it's
sensitive, but it does seem to me that if we're going to have that
commitment that it makes sense to make it real.
>
> Overall I was *extremely *happy with how the board meetings went. The
> board is populated by a very constructive group of people who work well
> together. They are very responsive to committer issues so any
> perception that committer issues take a back seat are definitely unfounded.
For the record, I also think that the Board is a good group, and
sensitive/responsive to committer issues. I didn't mean to imply
otherwise. But realistically, the interests of the various groups on
the Board (committers, strategics, add-in providers, EF, etc) do *not*
overlap completely...and that means that where they differ (e.g.
importance of tech innovation, importance of community and
collaboration, resource allocation, sustainability of community) it's
important that all committer's interests are well represented.
I don't mean to be pedantic...as I know you all probably agree with the
above...but I think it's worth saying occasionally.
>
> Was there anything else specifically you wanted to hear more about?
No, thanks. I would like to talk some face-to-face when we have a
chance, but nothing more right now.
Thanks again for representation and the information flow.
Scott
>
>
> Scott Lewis wrote:
>> Now that Europa is nearly in the can :), any public comments from the
>> Committer Board reps about the Board meeting last week?
>>
>> Scott
>>
>>
>> Ed Merks wrote:
>>> Scott,
>>>
>>> Thanks. I must confess that so far I think I've been doing a pretty
>>> poor job of being a committer rep. I've been too busy with all my
>>> own (EMF) issues to pay enough attention to the community's issues.
>>> As a group, we are now planning to have a call with Bjorn before each
>>> board meeting to discuss the issues that need attention at the next
>>> board meeting. More comments below...
>>>
>>>
>>> Scott Lewis wrote:
>>>> Committer Reps,
>>>>
>>>> I understand there is a Board meeting coming up next week (June 18)
>>>> and I want to start a dialog here about what committer issues may be
>>>> brought up/discussed before the Board.
>>> Good idea.
>>>>
>>>> Since the squeaky wheel gets the attention :)...as a committer, here
>>>> are my 'pet peeves' for the Board:
>>> Yes. Speak now or you forfeit the right to complain later. (I
>>> haven't forgotten your issue about needing incubating projects to use
>>> parallel IP.)
>>>>
>>>> 1) The IP process...for Europa and beyond. I continually have the
>>>> impression that all the work of the IP process falls on two groups:
>>>>
>>>> a) the foundation personnel (from outside it seems that more and
>>>> more foundation dollars are likely going to feed that monster) and I
>>>> don't see how that scales as Ganymede is even bigger than Europa.
>>> Yesterday we did discuss with Bjorn the lack of resource to handle IP
>>> reviews fast enough. We are all pinched by this and as the IP
>>> demands increase, this problem will only get worse. So personally,
>>> before the board decides to make any more decisions that will
>>> increase the IP burden of the foundation staff, I'd like to be sure
>>> that the funding for that burden is significantly increased.
>>>>
>>>> b) the committers (who do the work associated with adding license
>>>> files, about files, etc. etc.).
>>> It was incredibly frustrating to have this license file debacle take
>>> place at precisely the worst possible time for the committers who
>>> needed to contain it. In the future, the rules should be much more
>>> clear, and we should be addressing it early in the cycle, not during
>>> the crazy shutdown phase. Even the rules themselves are highly
>>> questionable. Having 1,000 copies of the license.html as well as the
>>> 1,000 copies within the properties files is just not a sensible way
>>> to distribute a common and consistent license; translating these
>>> files to multiple languages makes the problem even worse. So we'd
>>> like to discuss how to make this more sensible by referring to a
>>> single version at the foundation (and perhaps with a single local
>>> cached copy for disconnected installations). We should have these
>>> discussions early so that a new set of rules is in place long before
>>> the next crazy phase...
>>>>
>>>> The costs (on committers, largely) and benefits (commercial members)
>>>> are not equitable IMHO. I understand the benefit to commercial
>>>> members, but like I said I think the costs and benefits are not
>>>> equitably distributed.
>>> We discussed this issue yesterday as well. Working for IBM, I know
>>> there is a great deal of value in providing an IP clean result that
>>> can be consumed by commercial vendors. But I can see that the burden
>>> for making this happen is extremely onerous to the committer
>>> community, many of whom get little or no direct benefit from this.
>>> I'm also concerned that the battle of the open source licenses (LGPL
>>> is bad?) will affect our community in an adverse way. Sure it's a
>>> great thing that Eclipse builds components that can be used in
>>> anywhere, even for commercial products, but should there be rules
>>> that dictate that this is the only thing it should do, i.e., it
>>> should never provide integration with any LGPL library because LGPL
>>> is so inherently bad that we should build a giant firewall to keep it
>>> from tainting our perfectly pure and good EPL code? I would hope not
>>> (because otherwise Teneo could not provide integration with Hibernate).
>>>>
>>>> 2) The lack of company diversity on projects. I still think this is
>>>> a particularly insidious problem for the Board and committers...one
>>>> which I don't think the strategics or the add-on providers will do
>>>> anything about until pushed by the committers/committer reps.
>>> I'll just climb on my soap box and point out that the modeling
>>> project is a model of diversity and wait for people to contradict
>>> me. :-) I think project diversity is likely a problem specific to
>>> each project and you can't simply tell people to be more diverse and
>>> expect it will happen. I can certainly relate to why people might be
>>> concerned about diversifying their projects. There are lots of
>>> fly-by-night people in this world, and to have code dumped and them
>>> left behind is not something any of us want to handle. All that
>>> being said, I think diversity has great value and we should take
>>> steps to make it happen; it's certainly been a topic of board
>>> conversations already. And not to point any fingers, but starting
>>> with the platform as the model of perfection the rest of ascribe to,
>>> would be a good place. We need to ask ourselves why it is that the
>>> platform committer base has not diversified? I don't think it's
>>> purely an issue of people being kept out. I think many people are
>>> more than happy to take a free ride with occasional fits of wanting
>>> to dump their half baked solutions into the mix. (Feel free to
>>> contradict me!)
>>>>
>>>> 3) The 'project as technical silos' problem. Although related to 2,
>>>> it's not the same. Even if projects had representatives from
>>>> multiple companies they still might not be cooperating/collaborating
>>>> across projects. Especially with Europa, it's becoming clear to me
>>>> that there is a lot of duplication of effort/code/work across
>>>> multiple projects (e.g. ECF and DSDP and others all doing service
>>>> discovery stuff, etc). I don't think this is healthy for the
>>>> committers in the long term.
>>> I totally agree. I think part of the problem is that many projects
>>> create one big silo, so if you want a little bag of grain, you need
>>> to haul in the 18 wheeler and take on a full load. Smaller features
>>> like what we did for EMF recently would help. But features really
>>> suck and maintaining them is going to be kind of a nightmare.
>>> Perhaps the new provisioning story will be at least partially a
>>> panacea (and doesn't end up delivering "features" with a new word to
>>> label them).
>>>>
>>>> 4) The lack of membership support for volunteer projects. Does the
>>>> EF membership want only corporate run projects? If so, is this a
>>>> healthy environment for committers in terms of innovation and interest?
>>> I don't believe the foundation wants only corporate run projects.
>>> But keep in mind that the dominance of corporate interests at Eclipse
>>> is perhaps significantly driven by the apathy of those with
>>> alternative points of view (and perhaps by the poor job the committer
>>> reps do representing these alternative points of view). You being a
>>> notable exception of course. :-) IBM for one contributes huge sums
>>> of money by funding a large number of committers, so it's
>>> understandable that it will expect its interests to be well served by
>>> this large investment. But many of us also use large portions of our
>>> own personal time to make Eclipse great and I personally work hard to
>>> encourage a diverse community within EMF/EMFT and the modeling
>>> project that includes individuals, smaller companies, and academics.
>>> It's up to each of us to help balance the scales. And we shouldn't
>>> be too quick to overlook the extent to which corporate interests
>>> helps facilitate and fund the great community we are building.
>>>>
>>>> 5) Lack of follow-thru of strategic members on membership
>>>> requirements WRT people commitment. Each strategic member is
>>>> required provide a minimum of 8 committers (See Exhibit B in
>>>> membership agreement:
>>>> http://www.eclipse.org/org/documents/Eclipse%20MEMBERSHIP%20 AGMT%202007_04_04%20Final.pdf).
>>>> I'm pretty sure that a good number of the current strategics are
>>>> not meeting this requirement (even in name only), and I think the
>>>> result is greater burden on the strategics that are, and a greater
>>>> burden on smaller orgs and independents.
>>> Hopefully some of those folks are reading this and will feel
>>> sheepish. Just as it was time to review every license file we ship
>>> (because we'd all agreed to follow the not-so-clear rules), I think
>>> it's time to review the commitments the strategic members are living
>>> up to or not. It's always unpleasant to embarrass people though. :-(
>>>>
>>>> I suppose that's enough from me for now. I expect/hope that others
>>>> have input about what the committers should be discussing at the
>>>> upcoming Board meeting...and hopefully they will have the time to
>>>> discuss some of their plans in this regard publicly before the
>>>> actual meeting.
>>> Unfortunately I don't think we are so terribly well organized yet.
>>> Right now is an incredibly busy time for us "real developers". It's
>>> reassuring though that all the issues you've brought up in this note
>>> have been points of discussion already...
>>>>
>>>> Thanks to Chris, Jeff, Konstantin, Ed, and Darin for representing
>>>> the community.
>>>>
>>>> Scott
>
|
|
|
Goto Forum:
Current Time: Fri Nov 08 22:22:33 GMT 2024
Powered by FUDForum. Page generated in 0.03062 seconds |
] 
Search
Help
Register
Login
Home
