On Jul 5, 2005, at 9:19 PM, [EMAIL PROTECTED] wrote:
I was just thinking about the issues of external project
dependencies in
general.. Should there be a process for evaluating the introduction
of new
'critical' dependencies in Geronimo.
I think we should at least ensure that a 'critical' external
project meets
a minimum criteria, for example:
* An operational web site and documentation that describes the
dependency
(more than just a paragraph).
* Operational mailing lists and mail archives
* Operational bug tracking system
* More than one Geronimo committer on the project
The last one is a hard one. It's an ideal, but for well-established,
stable technology, I don't think we need to require this. (I'm
trying to find a good example, but can't at the moment)
Currently some of the projects being discussed in this thread do
not meet
the 'example' criteria above. Just picture yourself as a new Geronimo
developer wanting to get involved. Go to these project websites
and try
looking at the mailing list archives and see how much information
you can
find about the project.
What would be the impact to the Geronimo community if a critical
project
initially met this criterial then stops meeting the 'example'
criteria?
This is an interesting point. One of the side-benefits of using
dependences under the Apache license, or one as liberal, is that in a
dire emergency, we could copy the code and keep going with it,
assuming the community around such code died or decided to do
something really wacky, like re-license under the GPL, or completely
change functionality.
Have we identified the risks of depending on 'critical' external
projects.
I'm not saying we shouldn't rely upon them, but at least think
about the
risks and how they can be minimised. For example is it safe to
rely upon
these assumptions?:
* that the project host will always be operating
* that the project host will backup the project source (mistakes can
happen) and that we will always have access to the source.
* that mailing list archives for the project kept by the hosting
project
will always be available.
* that the bug tracking records for the project will always be
available
If Geronimo is integrating best of breed external components, then
IMHO,
the project infrastructure and community around those components
should be
well established.
I agree 100% and want to add more. We also want to be sure that for
critical components
- there is a healthy, diverse community surrounding the codebase
(which IMO is a short way of saying what you said above)
- we have reasonable belief that the code contributed to projects we
use is free of claims of copyright infringement or knowingly
"submarined" patents (we can never be sure about patents we
accidentally infringe...)
For the last point, we can *never* be sure of this elsewhere, just
like we aren't sure of it here. However, the ASF system of legal
documents pertaining to incoming IP via our ICLA and CCLA combined
with our practice of using the incubator and specifically tasking
each PMC to be vigilant and conservative about IP issues ("when in
doubt, punt to Incubator...") means we have a demonstrated and
visible structure in place. This seems to provide a good basis for
a) catching any problems before they happen and b) in the unfortunate
event that a problem occurs, protecting the ASF, the project and the
community as much as possible from things like claims of contributory
infringement, etc.
I think that copyright, patent and other issues are going to continue
to be the focal point for the larger debate about OSS and the
software industry, and given that Geronimo's community is growing,
and Geronimo is growing in usefulness (and thus value to users), we
need to always remind ourselves that these issues are of tantamount
importance to the importance of a solid, healthy community.
geir
John
This e-mail message and any attachments may contain confidential,
proprietary or non-public information. This information is intended
solely for the designated recipient(s). If an addressing or
transmission
error has misdirected this e-mail, please notify the sender
immediately
and destroy this e-mail. Any review, dissemination, use or
reliance upon
this information by unintended recipients is prohibited. Any opinions
expressed in this e-mail are those of the author personally.
Aaron Mulder <[EMAIL PROTECTED]> wrote on 06/07/2005
09:08:13
AM:
Changing the subject since we're drifting again. This is related
to another issue that's come up off-list, but we may as well open
it to
a
broader discussion here.
On Tue, 5 Jul 2005, Jeremy Boynes wrote:
TranQL is a Codehaus project so it is down to the despots, currently
me.
The barrier to entry is not high but so far I've not seen anything
except that problematic patch.
Okay. Well, without getting into specifics, I'm not real
comfortable with Geronimo being heavily dependent on a Codehaus
project
with precisely one, er, despot. I feel the same about the GBean.org
kernel, which while not currently a part of Geronimo, will likely
be a
candidate for it (and this of course is one of the issues around it).
Jeremy, would you consider either substantially enlarging the
community of despots for TranQL, bringing it to Apache, or merging
it into OpenEJB?
Dain, would you consider either substantially enlarging the
community of despots for GBean.org, bringing it to Apache, or
merging it
into Geronimo (as a branch or sandbox module for the present, I
presume)?
Thanks,
Aaron
--
Geir Magnusson Jr +1-203-665-6437
[EMAIL PROTECTED]
