My involvement with the Open Research Tools and Technologies devroom at FOSDEM over the past three years has greatly evolved. I went from being an analytical observer in 2020 (and want to thank the Inno3 team for introducing me to the devroom and its community), to participating as a talk presenter in 2021, to joining the organizing team in 2022-23.

Attending FOSDEM and the devroom in person this year (finally!) feels like a big leap, in what started as a slow and blurry process. It made me think a lot about inclusion and diversity, two buzzwords that are not stated in the devroom’s description, but that the community seems to want to engage with. Here are a few thoughts about that.

The way I see it, being inclusive and fostering diversity starts with an explicit intention.

Co-organizing the devroom assumes you are on board with the devroom’s objectives. Among others explicitly states on the devroom website, two big ones stand out to me in 2023:

• to build bridges between tool makers, users and designers of open source tools ;

• [in order] to foster a more inclusive & diverse environment around open source tool creation.

*[in order to] is between brackets because I’m not 100% sure about creating a causal link between these two ideas…

What does diversity & inclusiveness (D&I) mean in the context of this devroom?

To be clear, I don’t pretend to be able to offer any clear cut answers. However, these questions unleashed a train of thought about how this intention has materialized.

1️⃣ According to participants’ observations, the D&I intention has meant seeing more people who identify as female in the audience than in other FOSDEM devrooms. That seems like a basically good indicator to me and seems to be corroborated by numbers, as explained in this post about estimated gender ratios of various FOSDEM devrooms. (Thanks Paul for pointing this out!)

💭However, being a female doesn’t make me more inclusive of others de facto. Neither does it make me feel included as a female to be thought of as a quota, or showcased as a token, or counted. I’m not opposed to any of these things, just stating the way they make me feel.

💡I’m wondering, are there ways of offering recognition mechanisms (such as fellowships — non-monetary symbolic ones–) that might change the lens through which under-represented community members are perceived within the group of participants from the start?

2️⃣ From an outsider’s perspective, the D&I intention also seems to translate into a concern for balancing the number of invited presentations according to type: use-case talks (given by both men and women), tool talks (mostly given by men) and community talks (mostly given by women).

💭In order for this intention to result in collective dialogue and community-building (I’m assuming this is an underlying objective) there are structural conditions that make it likelier for that to happen, for instance, meeting in person and participating in hallway discussions. There are also physical limitations that make it harder, such as the classroom setting, and the fact that there is only one mic available, which means there is a pre-defined notion about what “giving a talk” looks like, and the audience literally has no voice by design. And, though it need hardly be said, there is nothing convivial about FOSDEM online.

💭Inviting and selecting talks on a referral basis is something that replicates structures and mechanisms used in selective academic and professional settings. The way I see it, it is extremely efficient because there is minimal on-boarding and a default  alignment with the collective’s status quo. People are enrolled because of a pre-existing interest and/or knowledge and this allows the collective project to move forward more unfettered than if it had to start from scratch to build trust with people from outside the community. That said, it is my experience that it’s harder to be inclusive and open to diverse views if you don’t forsake a bit of your comfort zone to engage with them.

💡What is the devroom’s comfort zone? Could “inside vs. outside the devroom’s comfort zone” become a selection criteria for evaluating talk proposals?

🔬 These questions should be relatively easy to answer seeing as both organizers and participants have engaged in self-analysis since the devroom’s inception. Several analytical and descriptive blog posts [3] [2] , two Twitter graphs [3] [4], and a semantic analysis [5] have been produced, and could help identify what that comfort zone looks like. What does the community want to do with this?

3️⃣ The D&I intention has meant reaching out to users, designers and tool-makers from different and usually dissociated professional spheres (academia, journalism, consulting, policy-making) and beyond traditional disciplinary fields within academia, like STEM & SSH.

💭Making a place for users, and validating those experiences as a form of knowledge, seems to be received very differently depending on the field. For instance, it still seems to be a very novel practice in French SSH culture, while it seems to have become central to French public service design. (I purposely won’t delve into addressing whether higher education is actually thought of as a public service in contemporary France).

💡Would it be worth intentionally pushing for a collaborative design approach of the devroom itself? Maybe more could be done to create a space for dialogue between the Open Source Design devroom and the Open  Research Tools & Technologies devroom ?

🔄I’m purposefully leaving this post open ended as I’m hoping it will become debate fodder 🤓 What do you all think?