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