[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [soa-iwg] Content of the Eclipse SOA Package
|
Hi Mike,
I can't speak to EclipseSource's desire as a whole for
membership/participation (without at least consulting with Jochen and
others...thanks for ccing).
See comment below.
Mike Milinkovich wrote:
Scott,
Does EclipseSource wish to join the SOA Industry Working Group as either a
Participating Member or Steering Committee Member? As a Strategic Developer
Member, EclipseSource would certainly be welcomed to the group under the
same set of expectations as the others involved.
Packages defined by IWGs are defined by collaboration and consensus of the
companies involved in the IWG.
I don't think this is a good model, frankly. It limits by definition
what can/should be included in the SOA packages...that are allowed to be
participant or steering committee members of this working group.
In this case, an independent project that I'm project lead for (ECF) has
taken on and implemented an OSGi draft standard (RFC 119) on behalf of
the runtime project...and this structure prevents effectively prevents
these contributions from getting into SOA packages...not based upon
whether they are relevant to the package (which I think at least I would
argue RFC119/Distributed OSGi is *very* relevant to SOA for the Eclipse
runtime project), but rather based upon the organizational structure of
the Eclipse Foundation membership (i.e. what their membership status is).
So although Jochen/EclipseSource may very well wish to be a
participating or steering committee member (and I would wholly endorse
this/argue for this as EclipseSource employee), even if they don't wish
to take on these roles I think this model of contributions to package
contents is severely limiting. For example, what happens when other
specs that are part of OSGi 4.2...and are potentially relevant to SOA
package (or other packages) are implemented by independent-run/started
projects at Eclipse? Again it would be rejected simply because of these
wg rules rather than on any notion of technical relevance (which, I have
argued, RFC119/Distributed OSGi certainly has for SOA). I'm not saying
what a better structure should be, but this doesn't seem right to me.
If EclipseSource wishes to actively involve
itself in the specification of the SOA package, I believe it should first
clarify its intended involvement in the IWG.
Like I said, I think EclipseSource can/may decide positively in
participation here...and I will argue for that within EclipseSource and
hope that EclipseSource decides positively. But if the decision is
negative from EclipseSource (whatever the reason), I don't think this
should prevent package membership for relevant Eclipse projects (like
ECF's work on RFC119). That just doesn't seem correct to me from a
consumer perspective (what these packages are for, no?)
Scott