Deadline:

# VIB Flagship Software Projects

## Context
VIB is uniquely positioned to make ground breaking scientific advancements due to the collaborative interation between research groups and core facilities. The skills of VIB researchers, technicians, and engineers all contributing to a shared vision. A grand vision, on a time-scale of 5-10 years is possible in this context.

## Introduction and Vision
The VIB Bioinformatics Core plays a key role in software development by maintening and repairing existing software produced by researchers and bioinformaticians. Though this
work is important and useful, it is also limiting. The
software engineers in the Bioinformatics Core could contribute
to a grand vision - producing software products with broud
utility to researchers. This framework would enable the
continued maintenance and improvement of VIB software
products beyond short-term needs.

## Proposal
Proactively develop scienfically useful software of broad utility beyond VIB. Such projects
would be on a larger scale than the typical software repair projects we currently see. It
would also require the involvement of multiple software engineers. Such a flagship project
would see ongoing maintenance and development and be worked on in parallel with our typical project workload.

Selecting a project would need to be a collaborative effort with the people who might be
interested in using the software: PIs, bioinformaticians, lab technicians, etc. Projects may target problems that are large scale and beyond typical users reach for solving. A selection process could involve voting on a set of possible
ideas.

## Advantages
The utility for research labs is clear and direct. They get useful, well maintained software. They have direct access to the software developers so bugs can be fixed and new features can be added in a timely way. Several other advantages stand out:

* Improve visibility of VIB through useful software tools
* Reduce wasted effort
* Proactive solutions to problems often result in better results

The VIB Bioinformatics Core is already involved in training. As the primary developers of flagship software products, the core facility is also uniquely positioned to offer training for said products.

## Potential ideas
1. Visual workflow editor (see #11)

| Layer | Description | Examples |
|:------|:------------|:---------|
| Application | Software projects with immediate and limited scientific application. | Single-Cell visualisation tools |
| Infrastructure | Software projects with immediate and broad scientific application. | NextFlow |
| Foundation | Software projects with distant scientific application but are fundamentally depended upon by the infrastructure layer. | numpy, libc |

## Resources

Application Layer

Infrastructure Layer

## Comments

- ~~aim at horizon 5 to 10 year~~
- ~~cover originality, how could the PI get back the investment~~
- Plugin denoising - structural support
- product development (longer term)
– is there a need, broadly applicable
- ~~link to training efforts
development of solution (tools)?~~
- ~~Product flagship~~
- ~~how to deal with maintenance of current project / outsourcing~~
- bioimaging projects
- link to multi Omics, spatial omics
- resources - align with current requests from bioinformatics community

text from: https://www.ucl.ac.uk/research-it-services/services/research-software-development

Computationally based research has the potential to set the **highest standards for openness, reproducibility, and reliability** in research methods. However, a lack of appreciation for the significance of software as a research output often leads to software created in research institutions being treated as a secondary concern. Research software is often developed quickly to solve **one-off problems**, leading to **fragile code that is generally not sustainable or usable beyond the lifetime** of a given project, and is hard for other researchers to read and understand. Whilst commercial software engineers tend to follow a more disciplined approach to software development, collaborations with academia can fail due to lack of understanding of the research context.
Our solution has been to create a **dedicated group of Research Software Engineers** at UCL who combine academic research experience with an appreciation of good software engineering principles. We provide a service which helps researchers to build **more readable, reliable and efficient code**. Our work is not just about producing software on behalf of researchers; we work collaboratively, providing the tools, advice and training researchers need in order to follow best practice and continue to develop sustainable software in future.

We also work with partners such as the Software Sustainability Institute to advocate on behalf of research programmers for software as a first-class research output. Research Software Engineers will be an important part of the twenty-first century research team, and building a stable home for these skills in academia will help secure for research the benefits of a high quality, sustainable software infrastructure.

# Notes from meeting 2020-Jun-24
Scribe: @MaybeJustJames

**Context from Alex**: VIB strategic plan.

**Saskia**: Good idea in principle. Selection process may be difficult. Don't want to be too early or too late.

**Bart**: Also a good idea in principle. People aren't aware of the software that might need to be developed/maintained. Referenced leaders retreat where people were asked...

**Saskia**: Groups that rely on software are very depdendant on the group that developed the software.

**Bart**: Commercialisation?

**Geert**: Commercialisation options should be explored given the opportunity.
How are these projects started? Idea might come from within a research group -> then you could immediately go to the software development experts.

**Saskia**: There's uncertainty about the potential popularity of a software project. How many projects do you maintain?

**James** and **Alex**: We not _really_ doing any maintenance.

**Geert**: Resource allocation is an important point (See Bart)

**Bart**: We can offer money, citations, visibility to the lab with the idea.

**James**: The difference comes down to the word "proactive". We should be going looking for projects rather than researchers coming to us.

**Geert**: Perception is important. People don't know that VIB BioInfoCore has software experts that can start from scratch.

**Saskia**: Agree. Need to put time in marketing ourselves to try to correct our perception or to tell people what we can do. Brag about what we can do!
Commericialisation might evoke an wrong reaction.

**James**: There are commercialisation options that do not preclude the software being open source.

**Alex**: Could also pay for services

**Bart**: Yes. These could include plugins. Scouting for projects is the right idea. Open call is difficult.

**Saskia**: If it's going to be a call we need to be very clear about what we're looking for. Everybody in VIB needs to know what we're for.

**Bart**: "The concept comes in and we're already there in people's minds."

**Geert**: Say, "this is what we do". It's about "unique positioning". We are talking about branding really. We should make clear to the field that we make impact. Have some pride in our package. and create buy in from more and more people.
Based on these 5-10 principles we can formulate a strategy.
If you reach out to management they will give you the resources you need. If we need 'x' extra resources and you have a good plan that's embraced by the community then we have a good chance.

**Saskia**: BioInfoCore is well positioned to takle the "helicopter view" of what could be useful. We can identify narrow vs. broad solutions. Research groups usually cannot take a broader perspective.

**Bart**: need to go bottom up (bioinformaticians -> PIs) not like now which is top down. Need to have good connections with the bioinformaticians.

**Geert**: The bioinformaticians will be our champions for this.

**Saskia**: Bioimage core went through a similar problem with calls from PIs. Going to PhD students and postdocs seemed to solve this.

**Geert**: First I would do is, right after this meeting, write down the 5-10 most important things and try to connect them and tune in a few slides. After this start talking to people.
Carefully position where you want to go.
Stepping into the process too late invites trouble.
Treat the PIs as equals rather than bic being the underdogs.

**Bart**: It's like saying that we're "partners" in the research of PIs.

**Geert**: Look to where we want to be in 5 years. Core facilities positioned as partners will be the ones still around.
Sell and resell and resell your message for at least a couple of months.

**Saskia**: We're not just extra hands and keyboards. Sell our expertise.

**Bart**: We can use the trainings for this selling too. BIC has the expertise especially if we're training on our software.

**Saskia**: We tried many things that didn't work. We hijacked their time when they're all together. We asked for slots where they're all together in e.g. scientific meetings (people didn't come). What was successful: talk to PIs directly (not really good in management meeting), can we have a slot in your team meeting?
Can pick out groups that could be most impactful.

**Bart**: Did the same thing. For us it is just bioinformaticians. Could try asking the bioinformaticians what they need.

**Saskia**: People didn't know that Bio Image core could/wants to take on big challenges.
Every year there are dozens of people graduating and going into research labs.

**Bart** and **Saskia**: You're welcome to use the tools you developed for us as bragging rights.

# Notes from Alex 2020-Jun-24
Accelerator

unique selling – branding

involved at conception

go to point – bottom-up approach / develop connections

Topics: Single cell / multi-omics / X

co-development / twinning partner

Identify the champions

fill in the gap

co-development / ink to training as well

How to reach out – tried to have

weekly seminar did not work

User group meeting

Talked to the PI – management meeting ?

team meeting – have a slot there (profile the landscape)

Bioinformatics /

UCL – see also

VIB – essential software development – good tools – come from within the institute – layer that is can be used, more than this niche application – use friendly

solutions are not big enough

which one approach is the best? Pro-active – how to recruit the projects

Jeroen Raes – person leaves and everything is gone
surprisingly few engagement by group

maintenance and training
users and imaging community – turn it

Yvan offers A-Z solutions – team remains a close box

science / competition ?

commercialization ? money could flow back to VIB / inventors

threat by those

Geert: start with the projects / start the process – count on expertise – over

maintenance ?

resources issues / repair / beginning / a lot of projects /

Resources – 5 FTE – impact researchers and beyond / co-develop software – money / visibility /
pro-active / mindset

Layers strategy

impact in a discipline / pro-actively – sit around the table

Narrow research problem

infrastructural software

How you are perceived? People do not know / marketing / perceived that bioinformatics core should do

denoising plugin / bioimaging core

Surf on open science

clearly say what is different / department – reach a lot of people