Galaxy: What should Galaxy be?

[jxtx]

At #GCCBOSC 2018 @nekrut and @jxtx asked, what should Galaxy be.

This is a place for responses.

[moskalenko]

Able to scale up, so MPI-based 'advanced' resource requests and environment setup for large-scale MPI jobs, perhaps.

Able to scale down, deep down, so a 'tool editor' like the workflow editor, but allowing to define tools and add code within the interface for experienced bioinformaticians to fill in gaps to remove any objection of galaxy resembling training wheels for biocomputing users.

[pvanheus]

@moskalenko for the 2nd I think there is a prerequisite: an execution model where tools run in encapsulated containers (a bit like IEs do), so that adding a new tool does not expose the Galaxy install to malicious code. If this is possible then a tool editor is effectively like an Interactive Environment.

[pvanheus]

My "what should Galaxy be": a provenance graph explorer - or maybe this is an overlay. It is a different "mode" of considering data in any event.

[pvanheus]

@moskalenko Can you elaborate on what goes into your first comment? And is this at all related to e.g. Kepler's model of pluggable directors (see section 3.3 from page 11 here)?

[jj-umn]

@pvanheus I would like a provenance graph. I've also had users request a print provenance report that could be used in publications.

[jmchilton]

I would like to see Galaxy move from a platform where contributors (tool developers, workflow builders, admins, etc..) are incentivized to contribute not because it makes it easy to share their work in an accessible way but because it simply makes it easier to do their own work - and the accessibility is a natural outcome. Put another way, people put extra work into developing stuff for Galaxy because of what Galaxy provides them - instead people should develop for Galaxy because it makes their own development easier and the awesome stuff Galaxy provides already should be natural outcomes of easy processes.

• Tool developers shouldn't be folks running Galaxy instances responding to user and personal requests, tool developers should be the application developers. They should want to write Galaxy recipes in order to profile their tools and integrate them into their own research pipelines (likely not GUI driven). The fact that they have a convenient way to share their work at the end of the process or during publication - should be a natural outcome of doing their work in a way they want to do it.
• Workflow developers shouldn't just be GUI users. Bioinformaticians working on production pipelines for themselves and for automation more comfortable with CLI tooling should see Galaxy as an attractive platform for development - they should want to develop for Galaxy because Galaxy makes it easy to write, test, distribute, profile, update their pipelines - and Galaxy providing an accessible, user friendly interface to their work should simply be a natural outcome.
• Admins shouldn't see Galaxy as another thing they can stick on their cluster to bring in new users to their compute. They should see it as the best, most easy to maintain gateway to a cluster. We should provide reporting, tooling, etc.. to make admins want to encourage Galaxy usage for all users.

Other things I'd like to see Galaxy be - these are each related to the above and stand-alone in a way:

• An obvious choice for large-scale production pipelines and research projects. Over the last few years, we've succeeded in making it a choice - I think we need to work on outreach and ease of use to make it an obvious choice.
• The best Common Workflow Language execution environment and an obvious choice for CWL execution, GA4GH WES backend, etc.. Galaxy's ethos of both pragmatism and accessibility when it comes to stuff ranging from standards to UX is needed and would help steer these efforts in great directions. I would like to see the distinction between what is good for these efforts and what is good for Galaxy breakdown completely.
• A dead simple tool to drop into Kubernetes, container services, Amazon Batch, etc..
• A set of libraries. I'd like to see both the backend and the frontend be smaller, composable pieces that can be integrated into diverse projects. I really believe Galaxy can be a collaboration platform even for non-Galaxy users/developers. Galaxy tools should be executable by any platform easily, other workflow engines should be able to tie into Galaxy job running, it should be simple to render the tool form from inside a Jupyter notebook, it should be easier to put smaller, alternative UIs on top of Galaxy or subsets of Galaxy.

[martenson]

• Radically domain agnostic platform that you can install domain specific extensions to.
• Provider of secured sandboxed reproducible environments for use with sensitive data.
• Most of @jmchilton's points

[hrhotz]

coming from the admin side, I like and fully agree with @jmchilton comments wrt to "Admins" - though I would like to add: ...they should see it as the best, most easy to maintain training platform.

Also, I would like to highlight again: we should further improve (or even just advertise) Galaxy as a collaboration platform even for non-Galaxy users/developers.

[bwlang]

I love these ideas @jmchilton