uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Eckart de Castilho <eck...@ukp.informatik.tu-darmstadt.de>
Subject Re: Contributing uimaFIT to Apache UIMA
Date Sun, 03 Jun 2012 11:10:20 GMT
>> 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
process
  * 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 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.

> 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

-- 
------------------------------------------------------------------- 
Richard Eckart de Castilho
Technical Lead
Ubiquitous Knowledge Processing Lab (UKP-TUD) 
FB 20 Computer Science Department      
Technische Universit├Ąt Darmstadt 
Hochschulstr. 10, D-64289 Darmstadt, Germany 
phone [+49] (0)6151 16-7477, fax -5455, room S2/02/B117
eckart@ukp.informatik.tu-darmstadt.de 
www.ukp.tu-darmstadt.de 
Web Research at TU Darmstadt (WeRC) www.werc.tu-darmstadt.de
------------------------------------------------------------------- 







Mime
View raw message