incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mattmann, Chris A (3980)" <>
Subject Re: [Proposal] Taverna workflow
Date Thu, 25 Sep 2014 16:14:26 GMT
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.


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
Adjunct Associate Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA

-----Original Message-----
From: Stian Soiland-Reyes <>
Reply-To: "" <>
Date: Thursday, September 25, 2014 9:03 AM
To: "" <>
Cc: Shoaib Sufi <>
Subject: Re: [Proposal] Taverna workflow

>On 23 September 2014 18:54, Marlon Pierce <> 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
>As an example of us/them impression - see Taverna's own website:
>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
>> * What is your strategy for increasing the diversity of your committer
>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.
>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
>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
>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
>> * Would you like developer-contributed plugins to be covered within a
>> "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
>To unsubscribe, e-mail:
>For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message