skip to content W3C SVG

Cross-disciplinary collaboration

Intro

Scientific Open Source projects are distinct in their collaborative nature between developers and scientists. This can take different forms – in some projects, scientists muscle through programming that they’re not entirely familiar with and seek help from developers down the line, some scientists have developers building tools for their use, and some teams are made up of devs and scientists working together to build the tool. But as one participant said, these projects are “interdisciplinary by necessity,” as they require both research/science and programming expertise to achieve their goals. Our research made it clear that interdisciplinary work at such a high level is tricky, but that many projects have made strides in understanding how to collaborate effectively.

Interdisciplinary work presents what many call a language barrier that makes collaboration challenging.

  • “Scientists and engineers think differently, but they don’t think they think differently”

  • “Designers and Scientists live in different spheres? Are designers in visuals? advertising? business? maximise clicks! metrics are extremely different to SROSS users. Scientists don’t care about animation/billboard design”…“Interdisciplinary is difficult, it’s almost like a language barrier”

  • “It’s all about communication, finding a common language, because that that’s another barrier that I found.”

Many scientists are not trained as programmers, or are only proficient in one language, which makes project maintenance and contribution difficult in certain project environments.

Many projects acknowledged that scientists typically do not have coding skills as strong as a traditional programmer. One participant begrudged this as a systemic issue: code development is not acknowledged as an integral part of a scientific career, when it should be.

Effective cross-disciplinary collaboration ranges in strategy and process. On the one hand, some projects prioritize mutual understanding and a state of continuous knowledge transfer between disciplines, while others take a more synergistic approach where each expert is able to excel in their domain without the burden of needing to know the “other” discipline well.

“I don’t have a PHD in astrophysics but I work with people who do, and my favorite hobby is asking questions.”

Some maintainers of projects were very interested in a kind of exchange-based collaboration between the developers and scientists on their team. Some approach this from an accessibility perspective, looking to lower the barrier of entry to code contributions or what code is doing in a project. One maintainer noted, “there’s a lot of people that would use our system that aren’t computational scientists. So all the code that I write, I really try and make sure that it’s as accessible as possible for someone who might not have coding background.” Beyond code, this strategy comes up in process and language as well. Some participants explained that they’re cognizant to ensure they’re “not making assumptions in the language that we use” when explaining OS systems to scientists.

On the other hand, some developers take an approach that allows each expert to “stay in their lane,” which to them, means giving everyone the tools and space to excel in their area of expertise. Such devs try instead to “take the code out of the way” in order for scientists to “not worry about the hurdle of learning programming to solve your problem.”

Perceptions that contributors need a precise skillset at the intersection of science and programming can be a barrier to finding contributors and converting users to contributors.

Some participants stated that a fundamental maintenance issue they experience is difficulty “finding folks with the right intersection of skills to be able to contribute to the project.” Lack of the right people, they said, means that the learning curve for contribution is steep, contributors do not understand the importance of software quality, and issues are more difficult to address because there aren’t enough properly trained people to discuss them with complexity.

Some, however, identified this attitude as a sustainability issue for these projects and the field in general. They advocated for ensuring access to collaboration between disciplines, but not requiring each contributor to know everything about both coding and science, especially for projects that are more niche. One participant described that for some projects focused on a very specific problem within a specific subdomain of science, maintainers have an idea that to be a contributor, one must “be both an expert in some type of compiled programming language, which is vanishingly rare among most life scientists, and you also need to be an expert in this very specific sub domain” of science. In this participant’s opinion, that requirement of expertise on both the technical and scientific sides meant foreclosing the possibility of contribution from people with one skillset or the other, and they advocated instead for “lowering the activation energy needed to engage with a project.”