In our initial grant proposal we stated that investigating the Implicit Development Environments (IDE) of technology is of special interest for the outcome of our research.
Technological processes and forms of organisation are commonplace: Not only since the rise of workplace anthropology it is widely assumed, that languages, (social) rituals, and even material environments like stations (laboratories and hack spaces, but also personal desks and machine layouts) are all inscribed in (user- or developer-facing) end-products.
IDE is adjoined to this motif and refers to “invisible” structures that influence the development of Software.
Such conditions can be governance models, protocols, systems, or tools. Another example can be the choice of Open Source itself as a practice of alternate political economy. IDE thus also necessarily entails values, convictions and potentials in owners, developers and maintainers of a specific project.
Being able to dissect the non-material aspects of technology from their material base in our hypothesis will eventually allow us to explore and operationalise how technological change as well as resilience or openness to organisational change, scaling or adaptation is evolving in projects, and who or what makes these processes happen.
In social sciences, non/semi-structured qualitative interviews are a proven method for uncovering needs, histories, priorities, hopes, and fears.
We argue that interviews centered around the narratives of developers and domain experts will provide the data points necessary to describe the actual context (critical) digital infrastructure is developed in and, hopefully, will help us to identify how support structures in funding already intersect with Implicit Development Environments.
Our aim is to uncover in these datasets, what practices and challenges have a positive or negative effect on organisational development in Open Source Software-Infrastructure projects.
As a result of an initial research design workshop with Simply Secure, we therefore grounded our research approach twofold:
- with literature review (find the accompanying blogpost here: https://implicit-development.org/2019/10/20/books-of-a-feather-ide-literature-review/), corroborated by
- semi-structured qualitative interviews with developers (with guidelines that follow a specific human-centered design), as well as unstructured interviews with domain experts and funders of open-infra-projects.
The concept of human-centered design takes into account (and puts emphasis on) the Social Shaping of technology-framework from STS, applied on vertical development environments.
Science and Technology Studies can be used to study software development as a complex, interacting system of people, organizations, culture, practices, and technology, or in its own terms: an “assemblage.”
To distinguish the different layers of the assemblage as well as the Software Stack, we relied on tracing implicit values through listening carefully.
As Simply secure wrote in their Luminate report, “On Trust & Transparency“:
With an interview guideline at hand, you “use the same topic structure and start in the same place, but by the halfway point, each interview turns into a semi-structured conversation“, strongly aligned with the perceptions and experiences of the respective interviewee.
As researcher, it is your task to meticulously record your interviewees reality, trajectory into software development and projects they´re engaged with, in order to then cluster findings and take a follow-up survey to zoom in on particularly (in)visible narratives. Closely following what the participant is saying is only one data-point next to body language and i.a. mapping out social graphs.
Key to this interview technique is also to establish a trusting relationship (for reference: https://simplysecure.org/blog/sensitive-interviews).
This hasn´t always been easy for us. Being rooted in two worlds (as (former) funders and researchers and the same time) partially allowed us access to candidates – sometimes it hindered it.
We assembled the first batch of interviews through references of former grantees (i.e. of Prototype Fund) and trusted allies in the ecosystem and were able to gather data fast, but only from a rather limited subset of actors. Subsequently, we also developed (and sent out) an interview screener, that was tailored to diversify our interview partners. It wasn’t welcomed as much as our first – more personal – approach.
As a preliminary (speculative) finding, it appears that open infrastructure projects at times are visibly protective of their domain knowledge and organisational structures, perhaps because of former experiences with funders metrics, or other reasons, that may also be implicit by nature.
The interviews so far have been conducted in fieldwork at work visits (retreats, workshops), as well as at academic conferences and domestic workplaces (even the interviewees’ homes, at times).
This localised approach will hopefully allow us to be able to respect the highly subjective conditions of each coder and project, while also enable us to abstract from subjective perceptions and identify common narratives in personal as well as organisational development.
After we concluded the interview phase, we will publish the interview guide here as well.
For the time being, you can find a guide by Simply Secure on how to assemble a balanced interview, with a mix of descriptive, reflective, clarifying and exploratory questions:
