incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stian Soiland-Reyes <soiland-re...@cs.manchester.ac.uk>
Subject Re: [Proposal] Taverna workflow
Date Thu, 25 Sep 2014 16:03:29 GMT
On 23 September 2014 18:54, Marlon Pierce <marpierc@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+Workshop

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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message