Skip to main content Site map
Old Tag
Open Source Software
Open Source Toolkit
Category
HomeNews and blogs hub

Open source AI/ML guided drug discovery workshop: translating learnings from Africa to LATAM

Bookmark this page Bookmarked

Open source AI/ML guided drug discovery workshop: translating learnings from Africa to LATAM

Author(s)
Gemma Turon

Gemma Turon

SSI fellow

Posted on 16 March 2026

Estimated read time: 6 min
Sections in this article
Share on blog/article:
LinkedIn

Open source AI/ML guided drug discovery workshop: translating learnings from Africa to LATAM

image of a group of people working behind computers

Image: Hands-on session ongoing at the Facultad de Ciencias Exactas y Naturales, UBA

The Ersilia Open Source Organisation, the research non-profit I co-founded and lead since 2020, was founded with a clear objective: equip laboratories in low-resource regions with open source AI/ML tools for infectious disease research. As part of our mission, we focus on three areas of impact: i) development of AI-based research software for drug discovery, ii) research in infectious diseases, and iii) capacity strengthening in AI. On the latter, we organise workshops on the application of AI methods for drug discovery and target medicinal chemists, molecular biologists, pharmacists and bioinformaticians in regions where these diseases are endemic. Oftentimes, we group the countries we support under the controversial “global south” term. While widely used to make a distinction between westernised or global north countries (a.k.a, Europe, North America and Australia), it lumps together very different countries, and is even geographically incorrect. Most of Ersilia’s work has so far been developed in Africa. Through a series of grant-funded events, we have delivered in-person workshops in South Africa, Cameroon, Kenya, Ghana and Zambia, and our experience in other “global south” countries, including the Latin American (LATAM) region, is scarce. Therefore, we were thrilled when the opportunity appeared to co-organise a workshop in Buenos Aires, Argentina.

For a successful event, having a local host that can support the event organisation, connect with relevant experts for course contributions and continue the networking activities after the event is key. In previous workshops co-organised with the H3D Foundation we have counted with the support of the University of Cape Town, the University of Ghana or the KEMRI, respectively. In this case, the connection arose naturally thanks to the Open Life Sciences program. After completing my own OLS training, I have acted as mentor for two Argentinian-based projects, MetaDocencia (led by Dr. Nicolas Palopoli) and TidyScreen (Dr. Alfredo Quevedo; Universidad Nacional de Córdoba). Through these collaborations, we identified a common interest in open science, LATAM-focused training and particularly, AI for drug discovery. Together, we designed an event with the following goals:

  • Learn how to adopt open source AI models for drug discovery
  • Understand the FAIR principles for research software
  • Understand and get experience in the use of Open Source AI/ML tools for cheminformatics and drug discovery: The Ersilia Model Hub, TidyScreen, AutodockBias, and others
  • Establish a community network of researchers and software developers in Argentina who are interested in utilizing open-source AI/ML tools for Cheminformatics and drug discovery.

At Ersilia, we were really keen to translate our learnings from African-focused workshops to this first event in LATAM, and adapt our content and training materials for future opportunities. Unlike other courses, on this occasion we counted with a strong local community developing their own tools for drug discovery, such as TidyScreen, which was a great starting point to consolidate a shared curriculum giving relevance to not only one, but several computational approaches to drug discovery. In addition to Ersilia’s and the University of Cordoba team, the facilitators included the hosts at the University of Buenos Aires, Prof. Marcelo Martí and Prof. Adrian Turjanski.

In this post, we try to summarise the key elements that made this course a success:

  1. Blending keynote sessions with hands-on practice with real examples. Previously we had to limit hands-on sessions to smaller exercises or less applied to real world, due to technical and infrastructural constraints
  2. Linked to the above, having a computer room set up for the entirety of the course accelerated troubleshooting and allowed for previous installation, system-wide of the needed software. This is truly location-dependent and we are really thankful to the University of Buenos Aires for their support.
  3. Focusing on reproducibility and training materials. Ensuring that participants will be able to reproduce the course, play with the software and propose improvements or make requirements based on their needs is essential to increase tool adoption. At Ersilia we always prepare a Gitbook for the course, and TidyScreen also has abundant and clear documentation and case examples.
  4. Demonstrating the relevance of open source software. The best demonstration of this is the integration of the Ersilia Model Hub, our flagship AI platform, inside TidyScreen. Dr. Quevedo and his team took the lead in integrating our software into their pipeline and showcasing how collaboration can bring more and better research outcomes
  5. Adapting the concepts to the local research interests. As much as possible, using context-relevant  examples makes the course more appealing to scientists. In this case, we focused on antibiotic-resistant infections and Chagas disease.
  6. Moving beyond English. While English is the predominant language in the scientific arena, we should acknowledge the limitations it poses to non-native speakers (including the Ersilia team). For example, we struggled previously in French-speaking Cameroon. Translation can be expensive and time consuming, but we fully advocate for it as much as possible. This time around, all course facilitators were Spanish-speaking, and the entirety of the course was delivered in Spanish, even though written course contents and documentation were in English.
  7. Allowing for in-person interactive time. While online training enables wider access, the opportunity to spend time together with students and other researchers sparks discussion and collaboration that is slower to build in online settings. However, to ensure equitable participation, we offered a hybrid course, and online participants could join in all sessions, including the hands-on.

In sum, we offered a course that blended several open-source tools for drug discovery from local (Universidad de Buenos Aires), regional (Universidad Nacional de Córdoba) and international (Ersilia) organisations, demonstrating how different research software tools can interact and complement each other. We had fifty in-person and twenty online attendees, and after the four-days course, participants left with a solid understanding of how to use the tools, guidance for implementing the learnings in their own projects and a network of contacts to expand their career opportunities and research interests, a networking that continued in the adjunct RICiFa conference. The support through the Further Development Grant from the Software Sustainability Institute (of which I am a fellow) was key to enable the participation of Ersilia facilitators in the event.

 

HomeNews and blogs hub

Be prepared to pay for open source (and deal with the consequences)

Bookmark this page Bookmarked

Be prepared to pay for open source (and deal with the consequences)

Author(s)
Patricia Herterich

Patricia Herterich

SSI Fellow

Shoaib Sufi

Shoaib Sufi

Community Team Lead

David Perez-Suarez

David Perez-Suarez

SSI fellow

Sarah Gibson Profile Picture 2025

Sarah Gibson

SSI fellow

Esther Plomp Profile Picture

Esther Plomp

SSI fellow

Irene Ramos

Sam Cunliffe

Jim Madge

Posted on 8 September 2025

Estimated read time: 7 min
Sections in this article
Share on blog/article:
LinkedIn

Be prepared to pay for open source (and deal with the consequences)

Green plant in clear glass vase with coins

Introduction

Open Source software is an essential part of our daily lives. Whether we are aware of it or not, we all benefit from Open Source. It powers the hardware we rely on to access the internet or critical infrastructure, and it may be a vital part of our job as developers or researchers to create and/or maintain an open source project. However, Open Source projects may struggle to remain sustainable for the long term. If you don’t want Open Source software projects to disappear, it is thus important to (financially) support them. Part of this support consists of being able to compensate individuals for their contributions - otherwise there will be an unequal playing field in who could contribute to these projects in their own time.

Different definitions of getting paid

In the cases where people are paid to make contributions to open source projects as part of their job, studies have shown a distinction in what exactly they are paid to do, and the impact that has on how they interact with a project (Zhang et al. 2024Dias et al. 2018).

At one end of the spectrum, someone may be ‘directly’ paid to work on a project. This means they are employed to contribute to a project and that is (one of) their primary responsibility. We would expect someone in this position to be deeply integrated into an open source community and its governance, because the objectives of their employment and the project will align closely. They will also likely, as a result of the way they are funded to contribute, have a significant influence within the community. This means they will have the soft power to steer the project and influence how it evolves.

At the other side of the spectrum, there are some new and long-time contributors who dedicate a part of their work hours to open source projects, whether that’s code-related contributions, community management roles, or something else. Their roles may or may not explicitly consider this as a main responsibility, and there is often a risk of contributions taking more personal time than the work hours allocated for this. This may cause conflict between their interests in the open source project, and their professional responsibilities.

Furthermore, there are different methods of financially compensating for contributions; some people will be paid as a fixed term or permanent contract, while others might be paid as consultants to contribute to research software. Permanent contracts offer stability, whereas consultancy can offer variability - some of this is being mimicked by institutional RSE groups that mandate their staff to work on at least two different projects in order to give them a variability in experiences. Alternatively, contributors to a project or community can be compensated for their time in non-financial ways. For example, they can receive mentoring or receive training and other opportunities to develop skills that might have otherwise required additional funding. One  specific example is the Google’s summer of code program, where a student may receive funding to work on a project, but the funding does not come directly from the project team providing the mentorship. This means that although the team will have to do the mentoring, they will benefit from the work that will be done by the student.

The effects of (financial) compensation 

Depending on the nature and size of the open source organisation, a person getting paid to work within a mostly volunteering community can produce a set of frictions and power dynamics (Zhang et al. 2024). In a volunteering organisation (whether it is an open source or not), it is understood that everyone is doing their best within the time they have available. However, when someone gets paid to do some tasks in the project, the expectations are different. What friction may this difference in expectations cause?

A paid individual will, most likely, have more time to dedicate to the project. This means that they will be developing and producing faster than the volunteers. Incidentally, the paid person has more time to think on the project, and that may give them more decisional power on what to do next. A paid individual may also not understand or know whether other contributors are paid or are volunteers, and thus may expect similar commitments from their peers. 

Holding volunteer contributors accountable may look different from paid contributors, and these processes need to be transparent for the community. For example, we have experiences from Google Summer of Code where new contributors get paid a stipend for ~3 months, and mentors help those contributors to get involved in the project. However, when the new contributors do not work enough on the project, the workload then shifts to the mentors, which may lead to burning them out. While holding volunteer contributors accountable may look different from paid contributors, it is still important that there are adequate safeguards in place to avoid these unexpected workload shifts.

Lastly, if the paid contributor is financially compensated by a company then this might conflict with the values of the open source project. It is thus important to consider the impact on community dynamics when the influence of a paid contributor grows?

What to do when a billionaire appears

Money might solve many problems, but only if you understand how to spend it well. As part of an Open Source software maintainer team it is important to understand how much money could make a real impact in your project or community.

A grant offers £50,000: Would that employ one person or get distributed amongst your contributors? Who decides this? Would all your contributors be able or want to get paid with money for their work? 

Similarly, if you find yourself in an elevator with a billionaire, what would you pitch you could achieve with £1,000,000?

All of this might seem wishful thinking, but this has happened before. Plan early and make sure you have community governance processes in place. Planning for something which ‘may’ happen can be problematic when people are stretched in terms of commitments but perhaps this can be tied into a wider piece on having a vision and roadmap for the project. Funders sometimes do have money that needs to be spent: Have your project ready to go so you can pitch it to them when needed! 

Conclusion

The Open Source ecosystem needs to be supported in order to continue to exist. This includes support from funders and organisations for Open Source projects, but also compensation for contributions by volunteers. Open Source projects should consider how they can facilitate contributions by both paid and volunteer members, and how these different types of contributions are impacting the community dynamics. When funding is available, having a clear vision and project roadmap to utilize the funding will ensure a more sustainable project in the long run. 

By ensuring that all contributors are compensated for their efforts, the Open Source ecosystem will be more inclusive of a wide range of contributors. 


Images by [1] [2] [3]

 

HomeNews and blogs hub

Survey on your perspectives on contributing to open source projects in academia

Bookmark this page Bookmarked

Survey on your perspectives on contributing to open source projects in academia

Author(s)
Oscar Seip

Oscar Seip

Research Community Manager

Posted on 29 July 2025

Estimated read time: 2 min
Sections in this article
Share on blog/article:
LinkedIn

Survey on your perspectives on contributing to open source projects in academia

Image summarising maintenance of open source

Calling all academic coders! We need your views on open source in academia 

In research, we depend on open source software daily, whether that's data analysis libraries, high performancing computing, specialist imaging frameworks, or out of sight in the stacks, but academic structures often don't recognise or support the maintenance work these tools rely on, despite increasing awareness of its importance and efforts to fund open source scientific software.

With the new UKRI software policy around the corner, it's never been more important to have a frank discussion about how to encourage, recognise, and promote both the use and maintenance of open source software in ways that benefit both individuals and the whole community.

This is why, as part of her SSI 2025 Fellowship, Arielle Bennett is running a survey to gather views from across the community, whether you are a casual contributor, a core project member, or someone who has never interacted with an open source project before. I want to explore what motivates, or blocks people from contributing to open source software projects and how we can improve participation in the future.

Who should respond: No prior experience contributing to open source required! Researchers, students, research software engineers, academic IT professionals, librarians, data professionals, and anyone interested in strengthening the relationship between academia and open source.

How it'll be used: Findings from this survey will be used in a policy briefing to help advocate for national policies which address common barriers at a structural level, and to develop practical recommendations for improving open source contribution levels across academia. Keep an eye out for a workshop at RSEcon 2025 if you'd like to explore this topic in more depth.

The survey will be open until 30 September 2025 and is open to researchers and research professionals anywhere in the world. 

Interested in discussing more? Questions? Contact Arielle Bennett 

 

The illustration is created by Scriberia with The Turing Way community. Used under a CC-BY 4.0 licence. DOI: 10.5281/zenodo.3332807

 

HomeNews and blogs hub

Announcing the 2025 “Impact of Research Software” Open Innovation Sprint

Bookmark this page Bookmarked

Announcing the 2025 “Impact of Research Software” Open Innovation Sprint

Author(s)
Denis Barclay

Denis Barclay

Communications Officer

Posted on 24 March 2025

Estimated read time: 1 min
Sections in this article
Share on blog/article:
LinkedIn

Announcing the 2025 “Impact of Research Software” Open Innovation Sprint

Open Innovation Sprint, a red running track

The first cycle of the Open Innovation Sprints has started. This programme aims to produce actionable, community-driven outputs designed to tackle shared ecosystem-level challenges in open source and open science. These sprints are collaborative, fast-paced initiatives bringing together researchers, engineers, designers, community organizers, and users over a six to nine month period. By the end of each sprint, participants release open source solutions, supporting documentation, and sustainability plans, all ready for immediate contributions from the wider community.

HomeNews and blogs hub

CSCEE to launch Birdaro project

Bookmark this page Bookmarked

CSCEE to launch Birdaro project

Author(s)
Denis Barclay

Denis Barclay

Communications Officer

Posted on 18 June 2024

Estimated read time: 2 min
Sections in this article
Share on blog/article:
LinkedIn

CSCEE to launch Birdaro project

CSCCE logo, a flock of birds in the background

The Center for Scientific Collaboration and Community Engagement (CSCCE) has recently announced the launch of a new project named Birdaro, aimed at supporting open source software (OSS) projects as they consider scaling and plans for long-term sustainability. The project has received funding from the Chan Zuckerberg Initiative.

The Birdaro project will focus on addressing common, predominantly human infrastructure-related challenges faced by open-source projects as they consider whether to scale. Specifically, it will concentrate on individuals taking on leadership roles within these projects. This initiative comes in response to the increasing importance of OSS products within STEM research and the growing need for support in ensuring the longer-term persistence of these projects.

CSCCE has been researching and developing materials about the challenges of scaling and sustainability in OSS that specifically relate to “human infrastructure” topics, such as community engagement, governance, the definition of roles and leadership pathways, and where projects end up being hosted.

The project aims to conduct further research in this area, create and share new resources, and develop a training program for open source project leaders. It is distinct from CSCCE but draws on the organization's expertise in human infrastructure.

"Birdaro" draws its name from the constructed international language of Esperanto, where it means flock of birds. This name is chosen to symbolize a collaborative effort where multiple individuals work towards a shared vision, similar to the collective movement of a murmuration of starlings.

If you would like to stay up to date with work on the Birdaro project, you can sign up today for the mailing list.

If you are interested in connecting with the Birdaro team to talk more about the project, get in touch at info@birdaro.org.

HomeResource hub

Top tips for managing your open-source project community effectively

Bookmark this page Bookmarked

Top tips for managing your open-source project community effectively

Author(s)

Malin Sandström

Estimated read time: 7 min
Sections in this article
Share on blog/article:
LinkedIn

Top tips for managing your open-source project community effectively

Have you developed something useful, and want to build a community around it? Before you encourage people to find you and your project, you need to make both easily findable. It is not hard, but surprisingly many miss or disregard this crucial initial step. You also need to figure out what type of people you want to find, and where they currently are.

Share on blog/article:
LinkedIn
HomeResource hub

Choosing an open-source license

Bookmark this page Bookmarked

Choosing an open-source license

Author(s)
Neil Chue Hong

Neil Chue Hong

Director

Tim Parkinson

Estimated read time: 8 min
Sections in this article
Share on blog/article:
LinkedIn

Choosing an open-source license

You've written some software as part of your research, and you would like others to be able to use it. You've made sure your code is ready for release so there's only one thing left to do: choose a licence.

Share on blog/article:
LinkedIn
Subscribe to Open Source
Back to Top Button Back to top