INSIDE EOSC 04 – Fotis Psomopoulous
Andrew Dubber
Hi, and welcome to Inside EOSC, a podcast all about the inner workings of the European Open Science Cloud. I’m Andrew Dubber. I’m a professor in innovation, a senior researcher at the Industry Commons Foundation, and I’m a consortium member of an EOSC project called LUMEN.
And each month I introduce, with no apologies made for the terrible pun, luminaries, people who are central to the Lumen project and also to the wider EOSC ecosystem. Today, I’m going to be joined by somebody who’s not part of the Lumen project, but is part of another sister project called EVERSE. I have a senior researcher at the Centre for Research and Technology in Hellas at CERTH, Fotis Psomopoulos.
Fotis Psomopoulos
Yes. Thank you, Andrew, for the introduction and many, many thanks for the invitation to be part of this discussion.
Andrew Dubber
Oh, you’re very welcome. Great to have you here. So we’re going to talk about EVERSE, the EOSC project you lead. But first, I’m curious about your journey.
What’s your background? How did you first get involved in EOSC?
Fotis Psomopoulos
My background is in electrical engineering and I am a computer scientist by training. But I quite like life science biology. So from my master onwards, I moved to bioinformatics, trying to do a bit of life science with computers.
So the main element at that time was to use infrastructures and putting research software together for doing analysis for life science data, for sequencing data. I realised that the need for computer infrastructure, of research infrastructure is quite high. And I got interested and more involved at different infrastructures at various times.
The first one I was quite involved in was the European grid infrastructure, EGI. And at that time, my main concern was how to use software, how to use the condition infrastructure provided, the standards into putting all those things together. Moving ahead, I realised that there are more domain specific infrastructures that I could take more advantage of.
And this is where ELIXIR came for. And with this is still quite involved in that one. And ELIXIR is the European data infrastructure for life sciences.
It’s an ESFRI. And what is a key point there is that it tries to combine and put together rather the standards, the expectations for various research components, data, software, et cetera. So in that case, my particular interest is around the software that is applied now.
Moving one step further to make the final connection to EOSC at some point, through this involvement with infrastructures, I came across the concept of open science. So I started getting involved in the early stages of EOSC through representing the training activities of Greece at the time and a few of the presentation from ELIXIR as well. And through that, I started to realise what EOSC is supposed to do.
Andrew Dubber
So there’s a couple of questions arising from that narrative, and they’re going to seem like the stupid questions, but hopefully they will unveil something useful in the process. You said infrastructures. What do you mean when you say infrastructures?
Is that the same as what I might consider a platform or is that something different again?
Fotis Psomopoulos
When I started the whole journey, infrastructures in my mind were like physical things, like computers that I have to have access to. They’re somewhere in the world and I can get access and use them. To an extent, that is still true, but it’s not the actual definition as far as I can tell, at least.
There are some infrastructures like EuroHPC, for example, which provide access to such consolidated physical computational infrastructures around different member states in Europe. However, a research infrastructure is something much more than that. It’s more of a community of people and work together across countries, across different member states in Europe, combined quite often, if not always, with physical components, which could be from microscopy to computational infrastructures to anything in between, but ultimately working together to provide services to the researchers, to the research community, to the scientific community.
And these services need to become standardised, to follow some good practices. And this is where the research infrastructure should actually do their main work, again, as far as I can tell.
Andrew Dubber
Right. Okay. So here’s the even stupider question.
When you say EOSC, what do you mean by that? And the reason I ask that, and obviously I’m familiar with EOSC, I’ve come across it before, but everybody seems to have a slightly different definition of what it is. What do you think of when you say EOSC?
Fotis Psomopoulos
All right. So I’ll start with a disclaimer. This is my perception of EOSC.
So no one should be taking this as the definitive definition of EOSC for what it’s worth. For me, EOSC is a European umbrella initiative that tries to connect and combine all the open science efforts that are happening, both at the national level, of course, at the member states, but also make them as interoperable as possible.
Across my passing or otherwise involved with EOSC, I’ve been getting different kind of perceptions from the purely technical point of view that EOSC is envisioned to become the equivalent of a cloud thing that everyone can connect, do the entire work, data analysis, writing documents, collaborate with others, up until the other point of view that is a regulation-slash-standards initiative that defines how open science should be performed. Right now, my understanding, or at least my interpretation, is that EOSC is something of both, as evidenced by the various EOSC projects, EOSC-related projects that are running right now.
There is a technical component that is permeating Europe. But more importantly, there is a concentrated effort to define what are the good open science practises, from how to do software, good quality software, from data management, FAIR open data, from using the same kind of formats, making sure that our research software is interoperable, to make sure that our documents are open, and having also an easy way to work with each other regardless of where we actually locate it. So that’s kind of EOSC for me.
Andrew Dubber
Okay, so you find yourself now as the coordinator of a project which is about software under the EOSC umbrella, or funded through the EOSC ecosystem. Now it took me an embarrassingly long time to figure out that when you’re talking about software in the context of EOSC, I think of EOSC as where research ends up and is shared and is made available, and that there are infrastructures, like technological infrastructures, that allow that to take place.
And what I thought was that the software was one of the enabling mechanisms that allowed you to share the research. And what I realised talking to you, software is the research output. So my first question related to that is, in what ways are software research?
Fotis Psomopoulos
I really, really like the question, and I will get off in a very long tangent right now. So both points are equally valid, and software can be used to facilitate research. Most, if not all of research right now is performed using software.
Data is the foundation, data is the knowledge, we need that. But given the huge amounts of data being produced at various domains, not just life science where I’m involved, but pretty much in any kind of domain, you need software to process it, as simple as that. And the better your software, the better your analysis, the better your knowledge that will be produced from the data itself, sure.
On the opposite side of the spectrum is research for software, how to make your software better, new compilers, new technologies, new ways of putting the bits and bytes together so that it can make the process work better. In between, there is the fact that software itself is a research output, and this is not always recognised, and this is one of my pet peeves, hence my enthusiasm in starting talking about this forever. This is something quite evident in every situation.
If you take any PhD student right now, most of the PhD students, most of the early career researchers are focussing on the data itself. They have their minds that they need to produce software to process that, but their primary concern is, how can I get the data? How can I produce the data?
Where can I find it? Software is a byproduct of the process. It’s the second, second class citizen.
And this is one of the main concerns that EVERSE is trying to address, making sure that software becomes a first class citizen in research as well. What does this imply? It means that, first of all, we need to disambiguate between any kind of digital output and data, and then have the research software somewhere in the bundle, which means that we need to have dedicated services to approaches that are getting software, not as a side effect, but as a core component.
And second, we need to have a common understanding of what we mean by saying that is good software.
Andrew Dubber
What are the benchmarks? I mean, I think of software as almost as something creative, like music, for instance. It’s like something that people do and that they share with the world and all the rest of it.
And this is good music and this is bad music. There are no real kind of objective markers for that. To what extent can you actually go through essentially a checklist and go, well, I don’t know, I’m sort of grabbing things out of the air, but this one is documented well, or this one is structured well, or what is it that makes a good piece of software?
Fotis Psomopoulos
And everyone has kind of a vague, possibly common understanding that this software is good or this software is bad. But being able to accurately or as much as possible quantify the characteristics of software, saying that this is good quality, this is good software, will make everyone’s lives easier. And this is something that EVERSE is actually trying to tackle directly.
So EVERSE is actually putting together both a knowledge base that will capture this formation and a quite exhaustive set of indicators. And I have to actually be very clear that EVERSE is not creating something that doesn’t exist. All these indicators, all these guidelines do exist if you start looking into the research software communities.
There are research software engineers, there are societies, very few, to be honest, but they do exist and primarily in few countries in Europe. But to answer the question specifically, I fully agree that creating software is a very creative process. However, there are some elements that can be quantified and objectively assessed.
The fact that you have tests for software is an indicator that at least you can see whether your input and output is consistently the same. Right. If you have a licence for your software, it might not speak about the software itself that edits code, but software as an element requires licence for able to be reused by others.
If it doesn’t have licence, I cannot do that. So there are a lot of points from clarity of code to tests to well-defined formats for input and output from how can you do version control of your code if you’re doing version control of your code. So all of those are good practices that can be transformed into indicators so that you can have a very holistic perspective, descriptors if you like, of a particular piece of code.
Whether as a community you define that this set of indicators is good or bad for you, that’s where the relationship with music actually comes in. If I want to say a piece of software in high energy particle physics, I may be quite interested to make sure that it can process enormous amounts of data in a reasonable time frame, but security aspects might not be that critical to me because it’s not a life or death question. If I have a piece of software that is going to be going to a medical device, I still want this to be fast, but maybe my priority would be, please don’t fail because someone might die from that one.
So indicators might be common. The importance might have distinctions based on the domain, on the scientific community, on the context of where the software might be used.
Andrew Dubber
I did an interview for this podcast series with Suzanne Dumouchel, who’s the director of the EOSC Association. And one of the things that she said, which I thought was quite interesting, was in terms of EOSC and infrastructures and these sorts of things, technology is not a problem. That’s the easy part.
People are a problem. Now, when you and I spoke recently, one of the things that you said that I thought was interesting that we must return to is you described your history with EOSC as long and complicated. Is that related in any way to what Suzanne had to say?
And maybe you could tell me the story about that.
Fotis Psomopoulos
Well, it is long and complicated for sure. And I absolutely agree with the assessment that it is always about the people. And I would go one step further saying that given that the relationships of EOSC with the various infrastructures and research infrastructures, because they rely on people, ultimately EOSC is a people thing as well.
And in terms of my complicated history with EOSC, because I start with a technical perspective in mind, I always found it much more complicated to engage and to figure out what I’m supposed to be doing in the context of EOSC or what EOSC is for me. Now, with a slightly bit more maturity in me, I absolutely agree that it’s the people that make it happen. And that’s why one of the key elements of EOSC in my mind is the training element, how to make people understand what is needed, how to provide this kind of upskilling to the different and communities to different people that will be involved in EOSC, not only or not just for the technical use on how to actually use the services that are provided, but more on their perspective.
If we’re talking about open science, do we all mean the same thing? If we’re talking about FAIR and open, does everyone understand the distinction between those two? Perspectives, the understanding of these principles, these themes is a critical aspect.
So I absolutely agree it’s about the people.
Andrew Dubber
Okay. So when you and I spoke recently, you were telling me about a three-tier system for software. Can you tell me a bit about that?
Fotis Psomopoulos
Absolutely. So EVERSE is using the three-tier system for categorising software.
It’s not a very formal thing, but it’s mostly used as a rule of thumb to figure out requirements, if you like, or broad categories of software.
Andrew Dubber
Where does it come from?
Fotis Psomopoulos
So it was first defined by Tom Honeyman from Australia, ARDC, and has since been adopted by a lot of research software engineering communities.
And it’s definitely one of the key cornerstones in EOSC. So the first tier is essentially code that is being used and produced by the same person or the same group. Code that is being done for a PhD project, for a thesis, for running some scripts.
This is our analysis code. This is the first tier. The expectations though, this is the more abundant one, as you can imagine, because everyone is using this kind of piece of software or they’re creating this piece of software.
For sure. But not too many other people are using this code. So if we go to the next tier, we’re talking about software that is being used by others than the ones that already created it.
And these are the first prototype tools, for example, libraries, this kind of stuff. So here we have more expectations because your code is going beyond your own kind of control. It’s being used by some others.
So you might not be able to go over their heads and say, yeah, what you’re going to do is not going to work because the code doesn’t work like that. You need to do this one, this one, which means that you have to have more documentation, more testing, be more usable by others. Make sure that some particular elements like tech information, readme, stuff like that are part of your code.
So this is your second tier. Less populous as a group compared to the first tier. And hence, the requirements are a bit more stringent here.
And finally, you have the third tier, software that is being used as a foundation for others to run their code on. The easiest example I can give here is Jupyter, for example, or any other infrastructure software that can be used to run others’ code on top of that. This is a large consortia working together to produce very complex systems of software, Galaxy being another one, that facilitates actual analysis discovered by others using libraries, using prototype tools, using everything else.
So this is the least abundant group of software, but also the more critical one. So the requirements there, the indicators for software quality, software excellence are much higher in that case.
Andrew Dubber
So again, stupid question, but just so I know, does open science software always mean open source software?
Fotis Psomopoulos
Excellent question. No. Open science means that you need to follow particular requirements for software. The code itself will ideally be open, but you might not have always open source software.
You might have some parts of your software being open. The key distinction that needs to be made is between open and FAIR. So open means that you have this available for everyone.
You can see the code. FAIR means that people can find the code. They know how to access the code.
You know how to interoperate everything, but they don’t necessarily have access to the code itself. It’s not open. You may need to pay for that, for example.
That’s a key distinction that is not always evident, but needs to, well, it needs to be clarified as much as possible.
Andrew Dubber
When you say FAIR, you’re speaking an acronym. You’re not saying fair in the sense that most human beings understand the term. Do you want to just unpack it a little bit?
Fotis Psomopoulos
Oh yeah, absolutely. Sorry. Expert’s blind spot, as usual.
So FAIR stands for findable, accessible, interoperable, usable. It’s an acronym that’s been almost a decade around now. It was defined back in 2013, 14, if I’m not mistaken, to encompass any kind of digital object, primarily being used extensively in data.
So we’re talking about FAIR data, for example. But there are particular efforts right now to make sure that the principles themselves are applicable and redefined if need be for implementation to other research outputs like software or machine learning models. Findable means that you are able to find your software, if I can do the explanation for using the software as the case study, which means that you need to have a DOI, for example, a persistent identifier.
Accessible means that you know how to get to it. So there’s an access protocol, it’s an HTTP, or it’s a URL that you can follow up. That’s kind of the process itself.
It’s closed. You might have some access control requirements you need to pay to get to it. But this is the accessibility part.
Interoperability means that you can both use a piece of software together as a chain, as a workflow if you like, but also to make sure that your software can run in different systems if need be, being able to utilise different components. And usable, I think this is the easiest one to explain. If I can have a piece of software, I can use it in a different case.
Someone else can pick it up and use it for their own needs, etc.
Andrew Dubber
OK, brilliant. So I understand now software’s place in the context of EOSC. Software is open science.
This seems like a good moment to talk about this project you’re coordinating, EVERSE. What is it? What does it do?
And what do you expect to accomplish by the end of it?
Fotis Psomopoulos
So EVERSE is an EOSC project. It’s a three-year one, started mid-2024. It comprises almost 20 partners across Europe, including some affiliate entities as well.
And more importantly, it includes all representatives, rather, from all EOSC science clusters. This means representatives from the different scientific communities in Europe under EOSC. That’s the structure.
It’s coordinated by CERTH and co-coordinated by BSC, the Barcelona Supercomputing Centre. And we are trying to be as active as possible, also reaching out to other communities that are not formal beneficiaries of the project. But I’ll get to more of that in a second.
To answer the question about what are the key outputs, there are at least five major outputs on EVERSE. The first one, and the flagship, if you like, is our knowledge base, the Research Software Quality Toolkit, the RSQ Kit.
This is a curated knowledge base of information about good practises, guidelines, information, recipes, if you like, around research software. Capturing aspects from open science, from FAIR software, to domain-specific questions, to very practical recipes on how can I put a licence to my software.
Second output is the Tech Radar. It is a collection of tools that address particular good practises or facilitate the improvement of the quality of your source code. This Tech Radar is envisioned to be a dynamic process, as well as the RSQ Kit that I mentioned before, because both of those things are created by the communities and are for the communities themselves.
Third output is a set of indicators. Again, as I mentioned earlier, this is not something defined new by EVERSE, but rather EVERSE is collating the existing information and the existing indicators that are being practised or used across both expert groups, that is the software engineer societies, or particular scientific groups, such as ELIXIR.
Andrew Dubber
Indicators of quality you’re talking about.
Fotis Psomopoulos
Exactly, in terms of quality. And fourth output is the Training and Recognition Framework. This is, again, I feel like going back and forth, research software is not being recognised as it should.
It’s definitely still considered a second-class citizen in science, maybe not to its face, if you can put it like that, but in practise, this is how it goes. So what we’re trying to do is, on one hand, define a robust system of how can we recognise contributions from software, but at the same time, how to combine this with concrete training activities, material on how to do good research in good research software, and how to produce software, how to assess, etc.
And the final one, and these, again, are the major ones, we have too many other minor ones, is the network. Essentially, a wider community of interested parties, interested people that want to be able to be part of the discussion and collaboratively contribute to these outputs because EVERSE is, in essence, a facilitator of putting, the focal point of putting those good practices together, of putting all those elements together. So if someone can contribute to that, it’s more than welcome to do so.
So putting the network together, that’s the goal. At the same time, it’s the other way around. If someone wants to be able to just use our outputs, the network is a way for them to navigate and figure out what we actually offer here.
Andrew Dubber
Okay. So you’re going to have, as a European-funded project, you’re going to have key exploitable results, you’re going to have KPIs, and all of those things you’ll tick off as, you know, we’ve done this, we’ve done this, we’ve satisfied the brief. When will you know that this was successful?
Fotis Psomopoulos
For me, success for any kind of an output of EVERSE is to see it being used by others. Seeing, for example, the definition of research software quality being adopted by EOSC would be an amazing result, an impact, if you like, of EVERSE. Seeing the research software quality toolkit, the RSQ kit being used and contributed to by people other than people within the project, this is also a success indicator in my mind.
But ultimately, truth be told, my ambition, or better say our ambition as a consortium, is to see EVERSE continue beyond the end of the project. Right. Not necessarily see EVERSE 2.0, but as an entity that continue and sustain itself and around this software.
Andrew Dubber
Well, we’ve talked about this as research software and software by and for researchers within the EOSC ecosystem. Do you imagine any applications of this outside of academia in, for want of a better word, the real world?
Fotis Psomopoulos
Absolutely. Although there is a very prominent perspective of academia and academic representative in EVERSE, by no means what we are putting together is constrained to an academic context. If anything else, in the network itself, we do have participants coming from industry and SMEs that want to either contribute to EVERSE outputs or just use what we are putting in place.
Ultimately, software is software. It doesn’t matter where it comes from. The fact that it’s of high quality makes it that much easier for a software that was initially created in an academic context to move on and have a different place or another life in the context of industry.
So we do expect, hope that everything that we’re doing in EVERSE is going to be equally usable by both industry and academia.
Andrew Dubber
So it makes sense to me to gather the outputs of academic research that is software. It makes sense to me to have some sort of indicator or validation of this is excellent software. I’m not sure I yet understand why this needs to be a specifically European thing.
And what is European about research software? Do you want to unpack that? First of all, obviously there are funding mechanisms that dictate that, but is there anything fundamentally European about the work that you’re doing?
Fotis Psomopoulos
So the short answer is no. Research software is software regardless of where it comes from. And that’s one of the key distinctions, if you like, between software and data.
And because we’ve recognised that, we are already establishing, we have established and we’re continuing to establishing relationships and to similar initiatives and efforts across the globe. We’re closely working with ReSA, the Research Software Alliance (ReSA), which is the headquarters are in Australia, working closely with similar initiatives that are led by NIH in the United States. And we have a very strong and continuously increasing relationship with Africa through the Connection to Science for Africa Foundation.
All of those initiatives are either directly tackling research software as a core element or have software as one of their main pillars, which means that working with them allow us not to act as the beacon of one truth, Europe says that this is the best, everyone should pick this one up, but rather a way to co-develop and co-create and learn with each other about the good practice for Research software. This is also one of the activities that the network within EVERSE is picking up.
And we have already participated in common activities, common workshops, common events across the globe, beyond Europe, where we’ve worked together with people representing these communities of RISA software from across Europe and beyond, improving what we currently have in good practices, indicators, training, recognition, all those things.
Andrew Dubber
It’s really fascinating because I think that there is something that is a potential that a project like this has to actually sort of expand the boundaries of what is considered to be not just European research, but research in general, and how these sorts of projects can imagine themselves outside of, or integrating the European context into a broader global perspective. Not just to sort of go, here is our European research and we share it magnanimously with the world, but what can we learn from out there? And I think that’s a really interesting approach that you’ve taken to this.
Fotis Psomopoulos
Exactly. If I can use the example of Africa, one of the key points that have come up, and I really need to have a shout out to Anelda van der Walt from Talarify in South Africa, who let us understand that some restrictions, some requirements have led to good practise that may be of significant value in Europe as well. If you can imagine an environment where connectivity is not that efficient, figure out what are good practise to maintain your software, to version control and everything else is a key activity, a good practise and an indicator that can be translated to something valuable in the European context.
So all these key points essentially can come by us discussing with similar initiatives, similar efforts across the globe with a very open mind. Research software is software regardless of where it comes from. That’s the key point.
Andrew Dubber
Okay, so we’re in the tail end of 2025. The project is progressing, but it’s also a time at which every conversation left to go on long enough eventually turns out to have been about AI.
And it does feel like there is a kind of an unspoken thing going on here, which is, doesn’t AI change everything? Like everything about what you’re doing?
Fotis Psomopoulos
Well, it does. Of course it does in software as well. I might have a hot take on that, so I’m not sure how well this will go.
So I’ll start with a disclaimer, EVERSE is not directly working with AI per se. And we are reviewing the capabilities of AI and what can be applied in software, but it’s not one of the core elements of EVERSE by itself. That being said, we have been looking into how indicators of software quality measure between AI-generated code and human-generated code.
And without going into too many details, AI-generated code period is usually slightly less good than code generated by a human being. However, code generated by a human being together with an AI is always slightly better than code generated by a single human being. But this comes back to my kind of game, another pet peeve, of how AI is being perceived right now.
Because I have the impression that, at least today, there is a big conflation between AI as a concept and the large language models and Generative AI, which is a very specific subset of machine learning and AI, for sure. In the context of these large language models, creating new code with no background, like a complete novice coming and writing code, it goes without saying that what’s going to be produced is not going to be sufficiently well-defined or with structural high enough quality. In the same sense that if I’m asking a chatGPT or something similar, a large language model, to generate a thesis on a scientific topic, for me, with zero background in that, what we produce will be something but probably not very good quality.
In the same sense, if a novice in software asks an LLM, create me code, it’s not unfathomable to say that your code will not be up to standards. But if you already know what you’re doing with the assistance of an LLM that you can guide and you can use as a support, then your code will probably be better. And that’s, again, my perception. I’m not representing EVERSE right now. That’s why I started by very clearly saying that EVERSE is not working on AI. But my personal opinion is that.
Andrew Dubber
There’s a quote from Steve Jobs I always think of when we have these conversations is that he characterised computers as bicycles for the mind. I like that notion when you think about AI because if you’re really good at riding a bike, you’re going to go further and faster and all the rest of it. But there’s also something in what you said which sounds like, whether it’s with an AI or with another human being, it’s collaboration that improves software.
Would that be fair? And I don’t mean sort of as an acronym.
Fotis Psomopoulos
No, it is a very fair assessment. There is also a technique called pair programming that is basically about people work together to write code. It existed for four decades now, five.
I remember seeing it like a million years ago. So working with someone to generate code, to write code and have someone else review your code, you review someone else’s code is absolutely makes sense. It’s a fair assessment that this is a way to improve your code.
If this other partner is an AI, it then comes down to how well your AI, your assistants, this LLM has been created to support you. Again, the same sense that I’m not going to be asking someone with a strong background in philosophy to write me a technical report, but rather I’ll find someone with a technical background to produce that. In the same sense, I should be selecting an LLM, an AI model that really is designed to facilitate code development.
To be my partner, I’m going to use a partner that I can trust, that I know it’s trained to do that. Run the selecting a random person to be my collaborator. Sure.
Andrew Dubber
Well, I’m going to stretch the analogy of collaboration because there are other EOSC funded projects as well. And I wonder if that same principle could apply. I’m thinking of LUMEN, obviously, in this respect.
Is there a way in which either of those or both of those could be advantaged by collaborating with the other or with other EOSC projects within that framework? What do you think the potential for that might be?
Fotis Psomopoulos
I think it’s an excellent idea. As EVERSE, we’ve already been working together with a lot of EOSC and non-EOSC projects together. I should mention explicitly FAIRCORE4EOSC, which was the first one that we actually established a memorandum of understanding to make sure that their efforts around this software were used within EVERSE and vice versa.
People from FAIRCORE4EOSC could contribute to what EVERSE has been doing. And we are looking into either formal or less formal collaborations with other projects. Because software is foundational, working with other projects is relatively straightforward because we can both learn what others are doing for software and pick this one up as a good practice.
If a particular community or domain has defined a good practice or indicator or training for software, I would love to have this as part of EVERSE and include that one. And vice versa, we can help people understand what could be good practise to improve their own code if they are so inclined. So that’s absolutely something we can look and work towards.
Andrew Dubber
It sounds like you’re not just talking about upskilling, but about shifting the culture within research. That’s a huge thing to aim for. How do you even start to approach something like that?
Fotis Psomopoulos
The only thing that I would like to emphasise, because I think this was quite comprehensive, and again, I’d really appreciate for the opportunity to be able to talk about my favourite subject, is how to make sure that we reach out to as many people as possible. The key challenge, the key obstacle in EVERSE and similar efforts is to change the perspective, the people problem that you mentioned at the very beginning. So one of the things that I want to emphasise as much as possible is that, although EVERSE is a funded project with whatever that entails, we have been actively trying from day zero to be as open for everyone to connect, contribute, and be part of the discussion.
And I’m not saying that in the sense you can, I’m expecting everyone to come in and start giving free labour, because quite often this is interpreted as hard. It’s the other way around. If you are doing something that I can incorporate or I can promote as a good practice, it would be great to know that.
If you want to be able to shape things because you see that what I put together is not valid or is missing something, a key perspective that has come from your side, this is something that we need to do. The EOSC and the expert groups are doing a lot in that direction as well.
But changing perspectives, especially for research software, is the biggest in my mind objective right now to making a big impact.
Andrew Dubber
And again, the ambition is quite something. I mean, Lumen is interdisciplinary where SSH, mathematics, molecular dynamics, and earth system science. And we’d like to look beyond that.
I mean, software is everywhere. You’re based in the life sciences, but EVERSE has got to be for everyone, from particle physicists to environmental researchers. How do you make sure the tools you’re building can map across all those different domains?
Fotis Psomopoulos
So EVERSE is by definition interdisciplinary. And the fact that I am working in life sciences and my domain expertise in life sciences doesn’t reduce the fact that I still have the background in community engineering, which means that by definition, this is, well, cross-disciplinary. The fact that I can write software for processing sequencing data doesn’t preclude me from doing something similar for data that is a time series coming from a sensor in climate monitoring systems, for example.
That’s the added value of EVERSE because it’s dealing with a foundational concept, research software. Having the backing, the active involvement of various communities from different domains into this many ones is a huge strength. The fact that we have representatives from various communities being part of the discussion allows us to mitigate as much as possible the risk, the bias of, this is software just for life sciences, we can ignore that.
That’s why every time I’m presenting this, because there’s always a perception, oh, this guy is from life sciences, so we can ignore that. We are in high-energy/particle physics. We are in something else, in environmental sciences.
I can ignore that stuff. This is not true. We are talking about software and software is the concepts, the foundational aspects of software are true across different domains.
Andrew Dubber
I guess the way to think about this is writing with code is interdisciplinary in the same way that writing with a pen and paper is interdisciplinary.
Fotis Psomopoulos
Exactly. I like the example. I’m going to steal it.
Andrew Dubber
Fantastic. Fotis, thank you so much for your time today. It’s been really fascinating.
Fotis Psomopoulos
Thanks, Andrew. Great to be here.
Andrew Dubber
That’s Fotis Psomopoulos, who is the coordinator of the EVERSE project, the European Institute for Research Software Excellence. He’s also a senior researcher leading the informatics lab at the Institute of Biosciences at the Centre for Research and Technology, HELLAS (CERTH). You can find out more about the EVERSE project, the research software quality toolkit and how to join their network at EVERSE.software. And I’m delighted to say that since we had that conversation, LUMEN and EVERSE have managed to hash out an MOU and we will be working together and sharing results from here on out. And that’s the Inside EOSC podcast. It’s a production of the Lumen project. I’m Andrew Dubber.
Thank you so much for listening and for sharing it with colleagues. Talk soon.