These are great answers, and much of them will help to guide the Incubation process.
Congrats guys and I for one want to welcome you with my Director hat and my ASF member and ASF guy hats! Cheers and looking forward to it. Cheers, Chris ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Chris Mattmann, Ph.D. Chief Architect Instrument Software and Science Data Systems Section (398) NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 168-519, Mailstop: 168-527 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Adjunct Associate Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -----Original Message----- From: Stian Soiland-Reyes <soiland-re...@cs.manchester.ac.uk> Reply-To: "general@incubator.apache.org" <general@incubator.apache.org> Date: Thursday, September 25, 2014 9:03 AM To: "general@incubator.apache.org" <general@incubator.apache.org> Cc: Shoaib Sufi <shoaib.s...@manchester.ac.uk> Subject: Re: [Proposal] Taverna workflow >On 23 September 2014 18:54, Marlon Pierce <marpi...@iu.edu> wrote: >> * Can you say more about why you want to take Taverna to the ASF? > >As we say in the proposal, one of our goals of moving to ASF is to >make it more obvious that we want to run an open development process. >So far we have effectively been leading Taverna from Manchester and >kept perhaps a too strong "ownership" - so any kind of request would >be responded to almost as if from a customer; our language would fall >into a we vs. them style. This makes the customers happy - of course - >but it does not encourage them to contribute themselves to the >project. > >As an example of us/them impression - see Taverna's own website: > >http://www.taverna.org.uk/about/ >vs >http://www.taverna.org.uk/collaborate/collaborations/ > >Under Apache, all of those should be "we". Currently we feel it >difficult to change this without having a separate foundation. We have >looked into creating a standalone Taverna Foundation - but found that >it requires a fair bit of legal administration. Apache is well >recognized, and has all the legal processes sorted out, and stood out >as the most viable candidate. > > >While we have tried to keep things open, with mailing lists, source >code, etc. freely available - our working philosophy has still been >entrenched in the office environment - strategic decisions about the >code decided in a coffee room meeting for instance, etc. > >Many of the non-Manchester contributors have mainly been adding >features in the form of plugins. Our software has a highly pluggable >architecture - so in a way that is also our fault - most of the things >people wanted to do could be achieved with a plugin. Those >contributors have not as much been engaged in any maintenance of the >core code, the engine and the user interface. Obviously it is also >more of a challenge to understand a whole system than just a plugin >interface, but still we don't want to keep any artificial or real >barriers for such engagement. > >So as much as our intended move to ASF is to further encourage others >to get engaged, feel ownership to the project, and to contribute to >the core; we also want to force ourselves in Manchester truly follow >an open process. > >By having Apache Taverna it is obvious as a standalone project - we >believe it could be easier for other scientific projects to bring in >contributions to Taverna as a part of their research proposals, >without a "need" to include University of Manchester as a project >partner or feeling that they are "giving Manchester something for >free". > > >> * What is your strategy for increasing the diversity of your committer >>base? > >We are organizing a developer conference next month in Manchester, >which has already generated a lot of interest and registrations. In >doing so, we have been inviting personally existing plugin developers >and integrators. > >http://dev.mygrid.org.uk/wiki/display/developer/Taverna+Open+Development+W >orkshop > >We in Manchester will want to keep those personal relations active, >and will work to encourage engagement from old and new developers - >particularly like when we found some integration "in the wild" where >the developers have not signed up to our mailing lists. A move to the >Incubator is in a way a good "excuse" for such recruitment - as it >means they should be feeling they are engaging with and becoming part >of the software project as an entity, rather than (as previously) just >communicating with a particular research group in Manchester. > > >> * Do you have any third party dependencies in the Taverna core that have >> incompatible licenses (like GPL)? > >Unfortunately we do have a few of those, yes - the fact that we have >to move away from those was one of the things that we discussed a lot >in the Taverna community. > > >Taverna 2 is licensed as LGPL 2.1, which meant we could use several >LGPL libraries like Hibernate and RShell. Hibernate can be replaced by >other JPA providers (with some code update to remove Hibernate >specific calls), while the RShell support would have to be moved out >to an separately installable plugin. > > >The Astronomy edition of Taverna includes a plugin called >AstroTaverna, which is GPL3 due to its inclusion of the Topcat and >STILTS dependencies. > >The AstroTaverna community was therefore a bit sceptical about moving >to Apache - but we concluded that as they would keep maintaining >AstroTaverna as standalone plugins and instead of having multiple >downloads for different editions, with Taverna 3 move to a "Start >screen" that installs plugins from possibly third-party sites (Eclipse >style). > >http://smtp.iaa.es/pipermail/astrotaverna-users/20140529/thread.html > > >Here luckily our plugin system (OSGi) will help us out - so those bits >that truly depend on GPL or LGPL would have to be maintained outside >Apache. What perhaps we need to prepare a bit clearer is exactly >which plugins will be in the Apache transfer, and which would stay >outside. > > >The Taverna Workbench installers currently include platform-specific >binaries of OpenJDK 7, which is licensed under GPL 2 with classpath >exception. It is likely that under Apache we could not distribute >OpenJDK - but perhaps it would instead be allowed to distribute the >normal JDK binaries? (For Taverna 2 we did not distribute the normal >JDK as it can be seen as incompatible with GPL, which LGPL can be >upgraded to). Do you know of any Apache projects that do this, like >perhaps OpenOffice? > >An alternative is for the installer to download JDK on demand - but >would that require the installer itself (currently Install4j) to be >replaced? > > >> * Would you like developer-contributed plugins to be covered within a >>future >> "Apache Taverna" project? > >As we've seen, keeping plugin developers on the "outside" of the >project has isolated them from the core development. We would >therefore like to encourage any new plugin developers to eventually >make their plugin a part of an Apache Taverna project - as we have >done historically with successful plugins. Apache's use of CLAs is I >must admit a bit of a hindrance to this as opposed to the Github >Laissez-faire style - - it has kept myself away from Apache projects >earlier when my suggested patch was deemed "significant" - yet the >legal department of the University spent 8 months reviewing that patch >and Apache's CLA before finally signing. > >Yet we consider Taverna to be such a mature project that we want IP >and licensing to be done correctly - and as you see our earlier >insistence on keeping CLAs for all Taverna 2 development means that we >are now in a position to relicense Taverna and change ownership to a >foundation like Apache. > > >-- >Stian Soiland-Reyes, myGrid team >School of Computer Science >The University of Manchester >http://soiland-reyes.com/stian/work/ http://orcid.org/0000-0001-9842-9718 > >--------------------------------------------------------------------- >To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >For additional commands, e-mail: general-h...@incubator.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
