On Jul 23, 2009, at 6:03 AM, Markus Karg wrote:
>> Markus Karg schrieb:
>>> While I still am not a big friend of the agressive style of
>> conversion
>>> you apply, I must confess that I fear that you are right. ;-( This
>>> is
>>> what I try to change, but it is hard as Oracle/Sun certainly do not
>> do
>>> this project for fun, but for money.
>>
>> Well... I guess most of these companies involved in open source
>> projects do
>> right this "for money", be that directly or indirectly. One thing
>> which
>> is
>> different about the Sun open source projects, here, in my opinion is
>> that,
>> ultimately, the source code of these projects is open and available
>> but
>> at
>> the end it seems to be nothing more than "open source Sun
>> repositories"
>> - no
>> real developer community outside Sun (feel free to correct me if I'm
>> all
>> wrong on that), no real community in terms of making decisions
>> regarding
>> project development and management, and so forth. This, ultimately,
>> makes
>> people suspicious as a lot of them (including us, actually) seem /
>> tend
>> to
>> rely upon open source software also for the reason of not being fully
>> dependent upon one special vendor providing this software (a
>> developer
>> friend of mine just recently had to experience this as Oracle decided
>> to
>> discontinue his beloved OAS in favor of WebLogic). So even being
>> "open
>> source", Glassfish won't eventually help preventing such a
>> scenario. :(
>
> Just what I say: The source is open, but the project is not -- but
> these days people expect open processes when reading about open
> source. Actually there is such a community outside of Sun which
> would be happy to participate in the decision making, but Sun is not
> offering an open process to let them participate. This is a
> difference.
I am sorry but I disagree.
The processes to define what goes in glassfish is much more open than
what you seem to think. First of all, even Sun engineers don't have
that much to say in what goes into glassfish because it's mostly
driven by specifications. Specifications are driven within the JCP and
are open to external participants so one good way of driving features
into Glassfish and others appservers is actually to participate to the
JCP process. Above the Java EE specifications, we have also released
all the product specifications by feature and that's also an
opportunity to add or criticize.
On top of that, we have had a lot of committers willing to participate
to the GlassFish project itself. I have personally tried to involve
some of these external committers to some task (yes they have to start
small so we gain confidence) but in general, the GlassFish project
being so big, the source code is intimidating, or the people just end
up not having the time, most of them don't follow up. We do have some
who participates daily and I don't think we ever kept them in the
dark. All meetings are open for anyone to join at least by phone.
At the end, I don't remember shutting out anyone willing to
participate (granted his level of participation was useful) but the
reality is that we cannot expect external folks to be able to spend
considerable amount of their personal time on the project which would
be necessary to not introduce more risks to a schedule.
For such a big project, the overwhelming size of the code, the time
involved in understanding enough of GF is probably the biggest barrier
to participation but it's certainly not a conscious decision from Sun
to hide anything.
>
> Regards
> Markus