uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marshall Schor <...@schor.com>
Subject Re: Contributing uimaFIT to Apache UIMA
Date Mon, 04 Jun 2012 13:12:39 GMT
On 6/3/2012 7:10 AM, Richard Eckart de Castilho wrote:
>>> uimaFIT is already under the Apache License. I suppose after the IP clearance
>>> is through, parts could easily be integrated into core. Any advice as to IP
>>> problems that may crop up is appreciated.
>> We will need a software grant - see http://www.apache.org/licenses/ .
> For uimaFIT, two software grants will probably be required as the project has been led
by people from two different institutions. Source code files correspondingly carry copyright
headers from the institution that first contributed the source file:
>    * University of Colorado           - Philip Ogren offered to take care of the necessary
>    * Technische Universit├Ąt Darmstadt - I will take care of the necessary process
>>>>>> 3a2) Pro: It could likely lead to some new committers :-)
>>> Definitely. We do want to continue developing uimaFIT. The development of
>>> uimaFIT follows a certain spirit, that we want to maintain beyond the formal
>>> contribution. There is also a number of issues on our to do list. I suspect
>>> that it will mostly be me doing active coding. Recently, Philip and Steven
>>> do less coding, but still contribute with valuable comments.
>> New code bases come into Apache either via the Incubator, or via direct incorporation
into existing top level projects, with an IP clearance done as it would be in the Incubator.
>> At the risk of saying what you may already know, the Incubator route is there to
enable a sufficient community to form around the project - Apache doesn't want "orphaned"
code with too few people able to commit to maintaining/developing it.  The Incubator also
is there to enable mentoring of new people in the Apache Way.  (See http://incubator.apache.org/
>> We have had other code bases come into the UIMA project via a direct path (with a
software grant, but not via the incubator).  In one of those cases, the people working on
the code were already working on UIMA - so were part of the community and were knowledgeable
in the Apache way of doing things.  In another case (I don't quite remember the details) -
we had the software in UIMA and the contributor was contributing patches (he wasn't a committer)
until we had some confidence he understood the Apache Way and would be a good team member.
>> Are any of the current people working on uimaFIT already Apache committers and/or
familiar with the Apache Way?  If not, can others comment on the rationale for picking the
incubator or "direct" paths?
> None of us is already an Apache committer. I have been participating for quite some time
on the users and developers mailing lists, have been active on Apache Jira and also submitted
the occasional patch. I do also participate in and lead other open source projects. Consequently,
I would think myself as sufficiently familiar with Open Source projects and with the Apache
Way to comment.
> I think a contribution in form of an incubator projects makes most sense for projects
that later graduate to top level projects (like OpenNLP). Given the scope of uimaFIT, a direct
contribution seems more reasonably to me.

I agree that the scope of uimaFIT implies a tight coupling to core UIMA, so it 
seems less of a "subproject", and more of a core contribution.

> I understand this is what has happened with the TextMarker project. It seems to me that
the direct way results is considerably less organizational overhead as well, e.g. no need
to set up a incubator project website and whatnot. There is some more overhead because the
protocol requires some time during which new contributors provide patches before being given
commit rights.
> A direct contribution could lead to a loss of identity to the uimaFIT project. This is
partially something that is desired, because we want to reassure users that uimaFIT is becoming
a part of the UIMA family and that using it is not "violating the UIMA way". It would be appreciated
though if some part of the identity could be maintained, e.g. by placing the module at the
same level as UIMA-AS. This would also make sense, as we would like to maintain an independent
release cycle.

We have designed the add-ons to be releasable either all together or (more 
likely going forward) as individual released things, so that's where I would 
suggest hosting the original uimaFIT.  Over time, of course, I hope the goal is 
for it to be properly integrated into the core.

>> Here's one comment - if there is only one active developer (at the moment) for uimaFIT,
it would seem that to accept this other existing UIMA contributors/committers would need to
agree to participate enough in uimaFIT so it had the minimal diverse community expected of
Apache projects.   At this point, I'm interested enough to be one of the additional participants
> I think the situation here is pretty much the same as with TextMarker. At the time of
the contribution (and I think to this date) there is one active contributor to the module.
There is interest amongst the other UIMA developers in the module though.
> As the situation stands, I am the only active contributor on uimaFIT. Philip and Steven
did not officially leave the project though and may choose to pick up their activities at
a later point in time.
> Marshal, it is great that uimaFIT could raise your interest to the point you consider
participating. Getting feedback, ideas or even code from core UIMA developers is most welcome,
as it paves the road towards the eventual integration of uimaFIT features or ideas into the
UIMA core in the long run.  I remember that last year, Jaroslaw Cwiklik had expressed some
interest in using uimaFIT for testing as well in the context of testing UIMA-AS.
> -- Richard

View raw message