Hi all, my 2c on this..
I'm thinking on a future potential scenario where astro-users would like to
benefit from existing functionalities/libraries developed elsewhere, and
they would like to have them integrated in Taverna. These apps are likely
to have their own licences, that could not be compatible with the general
Taverna Core CLA (whatever it is or should be in the future). How
seamless/difficult would it be for these external developers to adapt these
apps as plugins of the Taverna Core? I guess a minimal knowledge on how
Taverna Core integrates plugins is needed. And we should also think on how
to integrate them in a packed AstroTaverna plugin.. I think this scenario
is likely to happen in plugins like AstroTaverna, which is a *compound of
very different external apps/libraries*, and whose licence will need to be
compatible with licences of all its components. How do people in this kind
of compound-apps devel-projects deal with licences? Which is the ideal
level of plugin-granularity that could solve these issues? I'm tempted to
say the most extreme one, where every specific community maintains and
releases their own plugin.
As a user I would like to have a one-step install process, but the
impression I got from this thread is that this may not be obvious. In the
worst case I guess one configuration screen at the moment of installation
for selecting components/plugins to install could work as replacement for a
generic Taverna Wkbench Astronomy Edition.
2014-05-29 0:48 GMT+02:00 Stian Soiland-Reyes <
[email protected]>:
> Here's how OpenOffice present their support options:
>
> http://www.openoffice.org/support/index.html#community-support
>
>
> > OpenOffice Community Support
> >
> > The Apache OpenOffice Community Forum
> > The premier forum for OpenOffice users; immensely useful and
> recommended. Free support from volunteers in the community.
> >
> > Users Mail List (Subscribe / Archives)
> > Another community support option, via a public mailing list.
> You must subscribe to the list if you want to view responses to your
> question.
> >
> > Apache OpenOffice Native Language Mailing Lists
> > Mailing lists for several native languages.
> > Professional Services
> > On our Consultants page you will find a listing of individuals and
> companies that offer professional services related to OpenOffice
>
> As you see you can still do it very much as a "professional product". The
> only big change is who "we" is.
>
>
> On 28 May 2014 23:41, Stian Soiland-Reyes <
> [email protected]> wrote:
>
>> (CC from astrotaverna-users back to taverna-hackers. The discussion is
>> about pros and cons of a different management style of the project. See
>> http://smtp.iaa.es/pipermail/astrotaverna-users/20140528/thread.html)
>>
>> On 28 May 2014 22:34, Alan R Williams <[email protected]>
>> wrote:
>>
>>> On 28-May-14 21:51, Stian Soiland-Reyes wrote:
>>>
>>> [snip]
>>> '
>>> > No, sorry, this 'con' seems to not fully be true, it seems you CAN have
>>> > confidential conversations with the project's Project Management
>>> > Committee "private" mailing list - but it is encouraged to have as much
>>> > as possible done in public.
>>>
>>> How does this relate (if at all) to support questions? What would happen
>>> to [email protected]
>>>
>>
>> Anyone can provide support, of course - if myGrid will keep doing that,
>> then we may. It could possibly be listed as a 'Third party support' from
>> the Apache Taverna site, I guess we could no longer call it "official"
>> support.
>>
>> A better, more public and engaging option would be encourage support
>> through the mailing lists (probably still acceptable for developers) or
>> more modern Stack Overflow-like web interfaces (which is more what the
>> users expect today). That is part of the community building - getting a
>> graph-based support network rather than a star-shaped one. Apache don't
>> care too much about how and where users communicate, it is the development
>> that needs to be based at Apache.
>>
>>
>>
>>> > http://incubator.apache.org/guides/ppmc.html
>>> >
>>> > One could imagine in such a situation that the PMC would have broad
>>> > representation across committers and so would be able to make an
>>> > informed decission on such requests.
>>>
>>> Would committers to (say) the Stilts plugin count as committers to
>>> Taverna?
>>>
>>
>> Stilts plugin sounds quite specific - although its current direction (I
>> assume you are thinking of Christian Brenninkmeijers evolution from the
>> AstroTaverna one?) is moving more towards being a 'generic table plugin'.
>> If it depends on LGPL libraries, like STIL(TS), then it still can't be part
>> of the Apache Foundation's Taverna release. If we have many such
>> dependencies that we are unwilling/unable to give up, then we have to admit
>> that moving to an Apache is not ideal for Taverna.
>>
>> If the plugin stays as such, then everything is still fine (as long as it
>> is not a 'necessary' part of Taverna installation. For instance Apache
>> OpenOffice can optionally download GPL-licensed dictionaries on demand, but
>> works fine without dictionaries). Of course the developers of such plugins
>> would likely want to be part of the Apache Taverna community anyway (as
>> they would be part of the taverna-hackers community today); but not really
>> as a committer unless they have also been actively contributing to the Core
>> code base.
>>
>>
>>
>>> I think it's more common to have a release delayed until something that
>>> a project considers urgent gets done. Everyone else might have been
>>> happy without the special feature.
>>>
>>
>> So in those cases it could be that the Apache Taverna community would be
>> more pushed to get an intermediate release out without waiting for the
>> special feature; leading to additional work on doing two releases. So that
>> would be a downside, but it should be helped by moving to Taverna 3 and a
>> series of "often, but little at a time" kind of releases (which is tricky
>> today due to Taverna 2's plugin system requiring plugin re-releases for any
>> non-trivial Taverna updates, e.g. 2.4 to 2.5).
>>
>>
>> --
>> 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
>>
>
>
>
> --
> 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
>
>
> ------------------------------------------------------------------------------
> Time is money. Stop wasting it! Get your web API in 5 minutes.
> www.restlet.com/download
> http://p.sf.net/sfu/restlet
> _______________________________________________
> taverna-hackers mailing list
> [email protected]
> Web site: http://www.taverna.org.uk
> Mailing lists: http://www.taverna.org.uk/about/contact-us/
> Developers Guide: http://www.taverna.org.uk/developers/
>
------------------------------------------------------------------------------
Time is money. Stop wasting it! Get your web API in 5 minutes.
www.restlet.com/download
http://p.sf.net/sfu/restlet
_______________________________________________
taverna-hackers mailing list
[email protected]
Web site: http://www.taverna.org.uk
Mailing lists: http://www.taverna.org.uk/about/contact-us/
Developers Guide: http://www.taverna.org.uk/developers/
