Collaboration dynamics for space technology: the case of Satellite Networked Open Ground Station

This paper explores the dynamics of open-source software collaboration for networked satellite ground stations. Building on open-source collaboration literature, it examines how these dynamics unfold in a distributed technological space infrastructure that combines software, hardware, and operational activity. It does so through the case of SatNOGS, a globally distributed crowd-sourced satellite ground-station network operated by the Libre Space Foundation. To examine this empirically, we employ an exploratory mixed-methods research design that combines a quantitative strand, a Contribution Matrix (CM) mapping 148 contributors across 39 system elements, with a qualitative strand of eleven semi-directed interviews analyzed through the Framework Method. Findings indicate that SatNOGS software is organized around a modular collaboration structure, combining a large periphery dominated by single-element contributors (68.2%), with a small core of contributors responsible for much of the integration work. Interviews further reveal a distinctive group of paid and unpaid contributors, structured around specialist and generalist roles. Overall, SatNOGS is sustained through two coexisting modes of a dynamic collaboration: extreme modularity, which enables broad peripheral participation, and intertwined collaboration, which maintains system-wide coherence. This dynamic structure sustains the common project despite other governance-related challenges, i.e., contribution barriers or the lack of a shared roadmap.

The growth of low-Earth orbit activities over the past two decades has not only increased the number of objects in space but has also significantly changed who participates, the terms they operate under, and the tools they use. Orlova et al. (2020) describe this shift as the rise of a “New Space” ecosystem, where institutional sectors such as private companies, universities, and community groups now work alongside the national agencies that previously dominated orbital activities. In this context “space governance confronts a fundamental challenge because Cold War institutions cannot manage contemporary multi-actor expansion” of the sector, while transparency, as seen for instance in international space governance mechanisms, can create mutual accountability, yet increase perceived social cost of deviation from established norms (Affonso, 2026). More broadly, embracing diversity and complexity has been a recurrent challenge for policy and institutions (Ostrom, 2010). Specifically concerning open source and space technologies, the report Open Source Software Policy Options for NASA Earth and Space Sciences (National Academies of Sciences, Engineering, and Medicine, 2018) acknowledged the potential of the open-source approach of contributing to tackle contemporary challenges of the sector, as the openness culture also characterizes the scientific community. Nonetheless, the report raised the concern of the implementation of an open-source policy in a way that scientists’ contributions are recognized and taken into account for scientific career advancement.

Within this landscape, the case discussed in this paper - the Satellite Networked Open Ground Station (SatNOGS) project, operated by the Libre Space Foundation (Libre Space Foundation, 2026) - holds a unique position. It is one of the few infrastructure-grade space initiatives created and maintained as a digital and physical commons. It is also one of the rare projects that has achieved global coverage while mainly relying on volunteers. As an outsider initiated, international, open-source project is examined as a prominent field to explore contemporary challenges linked to transparency, international collaboration and related governance mechanisms in a bottom-up approach.

SatNOGS itself emerged from a longer trajectory rooted in Greek hackerspace culture of the mid-2000s. As it also happened with a number of technological communities which gradually moved from online forums and mailing lists into co-located collaborative environments (Lindtner et al., 2014; Moilanen, 2012), so did the community that later developed the SatNOGS: the Hackerspace.gr was established in 2011 in a semi-basement located in a popular neighbourhood of Athens. A win at the 2013 NASA Space Apps Challenge served as a moment of symbolic validation and a pivot toward more ambitious, hardware-intensive work for the early community. The SatNOGS project was launched in 2014 to address structural barriers in access to satellite ground-station infrastructure for small missions, amateur operators, and educational initiatives, and won the 2014 Hackaday Prize. Rather than treat the prize as an end point, the founding team reinvested the funding as seed capital for the formal incorporation of the Libre Space Foundation (LSF) in 2015, which subsequently delivered the UPSat satellite (Libre Space Foundation, 2026) and now operates the world’s largest crowd-sourced satellite ground-station network.

During the years that followed, SatNOGS met a wide expansion internationally (see Figure 1) seeing its number of stations rising sharply during 2017–2019. Then, the annual rate of new stations added to the network slowed during the following years, registering a higher growth rate during 2025 (see Figure 2). Through this varying yet sustained activity, the broadening of the project ushered its community in the “New Space”: an era, characterized by the introduction of new actors and business models, as well as unconventional practices and miniaturised devices for the space industry (Golkar and Salado, 2020), a movement promising a technological paradigm shift (Chrysos and Appio, 2024). Thus, SatNOGS became a large, complex open-source system and, at the same time, a child of the New Space era, putting forward the open-source way.

One of the effects of technological communities in general has been the emergence of new forms for technological development, where new modes of collaboration and established ones interact through tensions, echoing phenomena that historically emerged from Internet-mediated social practice (Benkler, 2017). Literature indicates that these collaboration dynamics constitute a challenging though interesting research field. The first tension is the one between paid and unpaid contributors. While recent research has shown that these two fixed categories behave different when taken in contrast (Miric and Jeppesen, 2023), the challenge set by Howison and Crowston (2014, p. 14) about understanding collaboration between paid and unpaid contributors in open-source projects as an “important topic for future research” remains relevant. A second tension, often overlapping with the first one, is between organization-based and community-based collaboration. The approach of community-based collaboration, for which open-source software development has been an exemplary case, has been challenging (Benkler, 2017; von Hippel and von Krogh, 2003; von Krogh et al., 2003) but also complementing previous paradigms on technological development (Howison and Crowston, 2014; Shah, 2003). Within such community-based settings, OSS-governance research shows that authority emerges through contribution histories, recognised roles, access to internal channels, and negotiated responsibilities rather than through formal hierarchy alone (O’Mahony, 2007; O'Mahony and Ferraro, 2007). This is particularly salient where community and organizational forms coexist, as O’Mahony (2007) distinguishes community-managed from hybrid governance. While the community model is most usually studied in fields of software and digital production, a third, more recent tension is between physical and digital, and the particular form of “phygital” binding the two together. When it comes to technological development, physical often refers to sharing software and design of devices that are fabricated locally (Kostakis et al., 2018).

In our research, we will refer to dynamic collaboration as an assemblage of the above-mentioned tensions expressed in our field of study. For rigor and relevance reasons, we will focus our research on the digital aspect of software development, as it is a process that produces accurate and analytical quantitative evidence. Yet, to contextualize this evidence and to further explore its relationship to the physical, organizational and professional categories, we will use insights from qualitative interviews with SatNOGS developers. These interviews will be analyzed in relationship with the contribution data using the same code names, when possible, to render context insights and collaboration evidence comparable.

The most influential frame for thinking about how large open-source projects manage their complexity relates to what makes open-source software (OSS) projects tractable in the first place. Baldwin and Clark (2000) supply the basic intuition. Once an artefact can be split into parts that obey a shared set of design rules, the limit on complexity imposed by any single contributor effectively dissolves. Lerner and Tirole (2002) make a similar point in economic terms. The ability to decompose work into distinct components is what allows volunteer projects to remain under control as they grow. Without that division, they argue, the effort would simply become unmanageable. Extending this viewpoint, von Krogh et al. (2003) support that modularity lowers the barrier to first-time contribution by giving newcomers a defined surface to work on allowing for experienced contributors to specialize in particular parts of the codebase without losing sight of the whole. Modularity, however, does not by itself make participation and integration easy. Lerner and Tirole (2002) describe a steep learning curve, particularly because newcomers must understand not only the modules they wish to touch but the way those modules interact with the rest of the system. von Krogh et al. (2003) introduce the notion of “joining scripts,” namely the loose set of practices, norms, and small rituals through which prospective contributors signal their intent and earn credibility within the community. Where these scripts are well-articulated, onboarding tends to follow a predictable arc. Where they aren’t, prospective contributors hit walls that have little to do with their technical skill and a lot to do with documentation, responsiveness, and the visibility of a roadmap.

Recent studies confirm that onboarding remains a central problem in OSS communities. Fronchetti et al. (2023) show that “contributing files” often fail to cover the barriers newcomers actually face, while Santos et al. (2025) find that many software-supported onboarding approaches still leave key barriers unaddressed. This more recent literature extends von Krogh et al.’s joining-scripts argument by showing that entry into OSS communities depends on both formal documentation and less visible socio-technical arrangements, including task discovery, development-environment setup, review practices, and community responsiveness.

The question of people’s motivation in contributing at all has been one of the more durable puzzles in this literature. Lerner and Tirole (2002) emphasize career and reputational returns whereas von Krogh et al. (2003), together with earlier work on user innovation by von Hippel (1988) and Rosenberg (1976), point in a different direction. These studies mainly foreground the private rewards that contributors derive from, for example, solving their own problems, fixing a bug that affects their own workflow, adding a feature they personally need, or customizing a tool to fit a particular use case. Neither account fully displaces the other. Most empirical studies find that contributors hold mixed motivations that shift over time, and that any given community contains people who arrived as users-with-an-itch and gradually became core maintainers, alongside others who came for the technical challenge or the social affordances of the community itself (Gerosa et al., 2021; Shah, 2006).

As regards the architecture of the distributed work, research on open-source projects has repeatedly found a sharply skewed pattern wherein a small core does the vast majority of the work, while a much larger periphery participates more sporadically, often through a single bug report, patch, or feature request. Mockus et al. (2002) early study of the Apache project found that the top 15 developers accounted for over 80% of code changes, and thus produced the bulk of new functionality, while a far larger periphery of around 140 developers contributed single tasks. This is a finding that has since been replicated, with variations, across many projects (Crowston et al., 2012). Hergueux et al. (2025) extends the observation to other digital commons, including Wikipedia, and treat it as a structural feature of voluntary participation rather than a pathology of any particular project.

The distinction between paid and unpaid forms of participation is crucial for understanding both the management of such projects and the broader governance arrangements through which they operate. Shah (2006), in an early treatment of the question, argues that projects in which paid maintainers work alongside volunteers raise governance and motivational issues that purely volunteer projects do not face. Volunteers and paid contributors often have different time horizons, different tolerances for tedious maintenance work, and different stakes in the project’s long-term direction.

Delving into the specific themes of contributions, von Krogh et al. (2003) show how the distribution of work reflects specialization. Peripheral contributors tend to focus on narrow features or incremental improvements to the existing system, whereas a small core group makes substantial contributions to the system’s development and evolution (Nakakoji et al., 2002). Howison and Crowston (2014) describe the extreme version of this dynamic, in which decomposition reaches a point where some developers contribute to only a single element of a project, as a “single-element contributor” pattern. The specialist–generalist distinction does not coincide neatly with the core–periphery distinction, however. Some peripheral contributors are deep specialists in a single area whose work happens to be one-off; some core contributors operate with a generalist’s overview but limited depth in any single module. Empirical research has only recently begun to take this nuance seriously (Chrysos and Sioumalas-Christodoulou, 2025; Gerosa et al., 2021).

However, a closer examination of the same literature reveals that core developers do not simply contribute more than peripheral ones but tend to do a qualitatively different kind of work. von Krogh et al. (2003) note that as the software architecture becomes more complex, a small group of contributors finds itself spreading effort/participation across many modules in order to keep the system coherent. This integrative work distribution cuts against the picture of clean module boundaries, because the people who carry it must hold a sufficiently broad view of the project in order to recognise when a change/amendment occurring in one place demands a corresponding change/amendment anywhere else within the entire architecture pipeline. Colfer and Baldwin (2016) explain this in the “mirroring hypothesis.” It predicts that a project’s organizational structure naturally should correspond to the technical dependencies between its elements. The team design should mirror the way constituent elements in the organization interact. MacCormack et al. (2006) further observe that proprietary projects, such as early Mozilla, require deliberate architectural changes toward modularity to enable open-source collaboration. In contrast, the study showed that established open-source projects like Linux were already highly decoupled from their inception. Thus producing an architecture for participation which lowers the cost of contribution. Linåker et al. (2024) describe a related phenomenon that relates to maintenance labour, arguing that sustainable OSS depends as much on ongoing integrative effort as on the visible production of new code.

Studies of OSS communities typically rely on two methodological approaches for acquiring evidence. The first uses qualitative methods, especially interviews and ethnographic engagement, to reconstruct contributors’ motivations, barriers, norms, and governance practices. The second draws on repository mining and software analytics, using commits, issues, pull requests, releases, and communication traces to infer the structure of collaboration. Recent work on OSS health and sustainability increasingly argues for mixed and multi-dimensional analysis. For example, Linåker et al. (2026) identify OSS health as a socio-technical construct involving community productivity and stability, orchestration, production processes, outputs, governance concentration, and strategic importance. Similarly, work on maintenance labor emphasizes that sustainable OSS depends not only on code production but also on the social and organizational arrangements that secure maintainer capacity over time (Linåker et al., 2024). These contributions urge researchers to move beyond narrow repository-based indicators and to examine the organizational, relational, and infrastructural conditions under which open-source projects remain viable. Such a perspective is particularly relevant to SatNOGS, whose sustainability depends not only on the production of software, but also on the coordination of distributed contributors, the operation of physical ground stations, the alignment of hardware and software components, and the ongoing integrative labor required to sustain a global digital-physical commons. Therein, the Contribution Matrix (CM) offers a methodological response to this problem by representing relationships between contributors and project artefacts, rather than treating contributions as isolated counts. Initially developed to examine the structure of technological contribution in open-source hardware and software projects (Chrysos and Desouza, 2019; Chrysos, 2017; Chrysos, 2016), and further applied to the SatNOGS case by Chrysos and Sioumalas-Christodoulou (2025), the CM makes it possible to examine not only how much activity occurs, but also how that activity is distributed across repositories, modules, and contributors.

Taken together, three interrelated gaps motivate our study. First, it remains unclear whether the patterns known from software-centred OSS projects transfer to digital-physical projects. OSS research typically studies contributions through code, repositories, modules, and core–periphery structures, yet projects such as SatNOGS enlist participants who may write code but may also build, operate, and maintain physical ground stations dispersed across the globe. The analytical problem is whether OSS theories developed around repositories and commits can adequately account for a globally distributed socio-technical infrastructure in which software, hardware, and operational activity are interdependent. Yet, to produce findings that are comparable with previous literature, our research will only focus on the software developed for this physical-digital system. Second, while the literature on open-source collaboration has mapped core-periphery structures and the motivational calculus of individual contributors, relatively less attention has been given to the variety of contributor roles that emerge within such communities, their interplay, and the way that interplay shapes development and integration effort. This is especially so in projects where the nature of contribution itself is more heterogeneous. Third, although the question of how distributed projects maintain system-wide coherence has been central to the OSS literature since Baldwin and Clark (2000), empirical investigation of the organizational and procedural conditions through which coherence is sustained, as well as the challenges that arise when those conditions come under pressure, remains limited in the case of commons, where coordination demands extend well beyond the codebase.

These gaps give rise to the following three research questions concerning the open source software development in the SatNOGS system:

RQ1: How is participation breadth distributed across SatNOGS’s repositories (elements), and to what extent does the resulting pattern relate with the SatNOGS collaboration core–periphery and modular-decomposition models established in the open-source software literature?

RQ2: What forms of participation and contributor roles emerge within the SatNOGS collaboration, and how does the interplay between them shape the project’s development and integration participation?

RQ3: How is the coherence of globally distributed software maintained, and what organizational and procedural challenges arise in sustaining its governance?

With the aim of addressing these questions the paper is structured as follows: First, the methodology section introduces the Contribution Matrix as an analytical framework, outlines the interview framework, and describes the data sources drawn from the related SatNOGS repositories. Next, the findings section presents the results, mapping the distribution of participation breadth across repositories and contributor roles. Finally, the discussion section interprets and contextualizes the emerging patterns in light of the open-source literature, examines the SatNOGS case in terms of coordination and coherence while considering the implications and limitations of the study.

This study used an exploratory, mixed-methods research design, unfolding on two complementary strands, rather than a single mode of inquiry. First is the quantitative strand, built from a Contribution Matrix mapping the way the collaboration took place. Second is the qualitative strand which was grounded in eleven semi-directed interviews that were coded through the Framework Method (Gale et al., 2013).

First strand: using the contribution matrix

The Contribution Matrix (CM) is a methodological instrument, first introduced by Paris Chrysos, to analyze the architecture of collaboration of a technological project: by mapping the relationship between contributors and system elements, complex dynamics such as in collaborations between volunteers and paid contributors (Chrysos and Desouza, 2019; Chrysos, 2017) can be examined based on collaboration evidence. The CM has been used to analyze the development of other open-source space technologies (Chrysos and Appio, 2024), as well as in other fields, such as neuroscience, to analyze the relationship between contributors and research elements (Steinmetz et al., 2021).

The CM allows the joint analysis of actors and technical systems, usually studied separately and by different disciplines. On the one hand, the Social Network Analysis (SNA), grounded in sociological theory (Granovetter, 1973, 1983), consists in analysing the social relations between individuals engaged in a specific activity (“who relates to whom?”), without examining whether or not individuals make use or contribute to a specific technical system. This approach helps understand social systems, such as civil society collaboration (Marshall and Staeheli, 2015), where a technical substrate can be of low importance or even absent. On the other hand, engineering approaches on systems analysis focus on the technical side, without examining the dimension of the contributors themselves. Synthesizing the ways software repositories are usually mined, Soliman et al. (2025, p. 8) only identify methods that examine exclusively the technical aspects of the system (architectural quality issues such as vulnerabilities, architectural descriptions or design decisions). At a more theoretical level, the Design Structure Matrix (DSM, Browning, 2016; Baldwin and Clark, 2000) maps the relationship between the elements of a technical system (“what depends on what?”), without examining the specific participation of their developers. While the SNA explores the social structure of collaboration, the DSM explores its technical structure. The CM allows for a joint analysis of the technical and the social focusing at their interplay. This is the particular emphasis of our study, having as a criterion the question “who did what?” The first strand of our paper is thus built on prior research elucidating the way in which the CM can be used for the analysis of the SatNOGS project (Chrysos and Sioumalas-Christodoulou, 2025). As the latter explain, “within a collaborative process where multiple actors create a complex system consisting of many elements, the CM indicates whether an individual (contributor) has contributed to the development of a specific element.”

The CM is constructed by arranging the elements of the system in columns and the individual contributors in rows. If a contributor X contributes to the element i, then the cell [X, i] takes the value 1, otherwise it takes the value 0. The design of a CM is summarized in Table 1. In this example, we have assumed that Contributor 1 has only contributed to Element 1, Contributor 2 to Elements 1 and 3, while Contributor 3 only to Element 3 and so on.

In our field of study, the elements of the system are the SatNOGS repositories: an open-source project where the collaboration took place through a commonly used digital setting, GitLab. There, contributors submit their contributions, and the digital system keeps track of who did what (commit logs). Collaboration traces (Chrysos, 2016) were retrieved from the Libre Space Foundation GitLab group in March 2026. The CM was constructed using the available commit history of the repositories present in the GitLab group at the time of collection (March 2026). To define the temporal scope of the data, we rely on Git’s committed_date, rather than GitLab’s created_at indexing field. On this basis, the earliest contribution included in the CM dates to April 2014. The CM therefore captures the available GitLab history of the included repositories, including every commit present in repos that exist to this day, even before the migration in 2018.

For accessing the traces, we used the GitLab REST API to retrieve the list of all available elements (repositories) of the project. These traces include data retained by the setting during each contribution: commit identifiers, time stamps, contributor names and e-mail addresses with which contributors signed their contributions. A first version of the CM was then constructed based on the correlation between contributors and elements. Of course, a limitation of this method lay in the fact that those contributing to other elements beyond software were not taken into account. Yet, the choice of focusing on the contributions in the software provided a very high accuracy of collaboration data for this specific part of the project.

Furthermore, we proceeded to the vetting of the resulting database to eliminate duplicate accounts and software agents. On the one hand, 25 contributors had more than one account, which were merged for a contributor to be represented by a single code. On the other hand, some accounts clearly represented automated commits (bots), used for operations such as maintenance upgrades, and were removed. Finally, we cleaned the database from inconsistencies (bad data). An example of bad data are empty lines and duplicate entries. The resulting data set was then reviewed again to verify the accuracy of data (emails, names, contributions to elements). Last, we validated the correspondence between accounts and contributors as well as repositories and elements of the system during interviews with the members of the LSF organization.

After performing data cleaning and homogenization techniques, in order to rearrange rows and columns in accordance to their similarities in contributor-element profiles the Hamming-distance seriation was used. This enabled us to better order and visualize contributors with similar contribution profiles, making co-occurrence patterns easier to inspect. Such an approach is established for matricial data and is based on the calculation of Hamming distances (Brusco et al., 2021; Daugman, 2009). The resulting CM is shown in Figure 3. (Analytical data are provided in the Supplementary material).

Second strand: operating semi-directed interviews

Our research focuses on software collaboration, a part of the field allowing for accuracy and comparability to the widest part of the literature. To contextualize the CM findings and enrich our analysis, we use qualitative insights from semi-directed interviews with SatNOGS developers in a complementary way to the CM data evidence. To this end, we conduct a thematic analysis using the Framework Method (Gale et al., 2013) to produce a table that synthesizes our findings.

Initially, we follow the seven stages of the Framework Method (Gale et al., 2013), beginning with the transcriptions. Each interview was recorded with informed consent and transcribed verbatim. To transcribe we used the help of AI tools, and the transcripts were then checked against original audio for accuracy. The second stage was familiarisation, where we read each transcript closely in order to become familiar before coding. The third stage was coding: our coding was deductive, the codes were pre-selected from previous literature and theory rather than generated freely from the data (Gale et al., 2013). We read each transcript and applied these codes to the relevant parts. The fourth stage was development of a working analytical framework. After coding the first interviews, we compared the coding and agreed on a shared set of codes. After the comparison we grouped them into axes and gave each code a clear definition and rule. Each axis is a broader category that groups together codes addressing a related aspect of contribution. The fifth stage was the application of this framework, where the fixed set of codes and rules was applied to all 11 interviews, achieving consistency across all the interviews. The sixth stage was charting. We summarised each interview into the Framework Method Table (FMT), with the interviewees as rows and the codes as columns, and scored each code with a scale 0/1/2. A score of 0 means the interviewee did not mention the topic at all. A score of 1 means that the interviewee mentioned or acknowledged the topic. A score of 2 means that the topic was a key part of the interview, the interviewee discussed it in depth, spoke from direct experience, or described it as a structural feature of the project. Finally, the seventh stage was interpretation. We added up the scores in two ways. For each interview, we calculated a total score for each code and axis. For each code we counted how many interviews mentioned it, and we found its sum, average value, and coverage percentage. By comparing these numbers within and across interviews, we reviewed the codes and defined themes. Because the starting codes were shaped by prior literature, we treat these themes as contextualising and elaborating the categories rather than independently confirming them.

More specifically we conducted 11 semi directed interviews with SatNOGS contributors, the vast majority of which are already present in the CM. The flexibility of open-ended interviews allows for the exploration of unexpected topics that may arise during the discussions, which can then be integrated into the analysis. This format was chosen because it encouraged the surfacing of participants’ personal accounts and experiences, thus capturing nuanced opinions and allowing the faithful representation of their beliefs. Structured guiding questions were used in these interviews for verification of the consistent coverage of the topics at hand. The complete, anonymized list of interviews taken is shown in Table 2, where payment status, as emerged from the interviews, has also been indicated.

Interviewees were sampled and named purposively to reflect the three groups visible in the project’s contribution structure, as identified with the CM: The SatNOGS core (seven interviewees, five paid LSF staff and two LSF volunteers with broad access to organizational data) and the Periphery [four interviewees, one university-based contributor (C49) to elements E36 and E38, one satellite-mission decoder (E31) team (C123) and another high-volume satellite decoder (E31) contributor (C51)]. The data elaborated in the CM are publicly available and thus researchers could replicate the identification of individuals or their aliases, as we link the interviews using the same code names. However, for courtesy reasons, we insist on coding of contributors rather than mentioning their own names or aliases.

To contact the interviewees we used three different approaches: initially, we used the emails from the previous step to reach out to the contributors. In parallel, we directly contacted LSF members via the organization’s chat. In addition we used the interviews themselves to further identify contributors to the interview. The interviews were conducted in Greek or in English depending on the participant. Their duration ranges between forty-five and ninety minutes, they were recorded with informed consent and transcribed verbatim. The position of each interviewee in the CM guided our questions to shed light on the relationships between interviewees and other contributors as well as on their knowledge of elements to which they have contributed and those where no contribution trace had been found. An effort was made to interview contributors from all parts of the CM, however the response rate was relatively low: we managed to interview only 11 out of 148 contributors, thus those qualitative findings are rather used to provide context to the CM data. This early step of the qualitative analysis echoed the CM results: albeit numerous, the contributors of element E31 were much harder to contact and to eventually interview, a difficulty indicating a distantiated position of the E31 contributors in relation to the rest of the community.

Overall, the questions covered topics related to the contributions the interviewee has made, how they are being integrated and the manner in which their own contributions interact with those of others. Then, to construct the FMT, we summarized each interview and charted them against a set of mutually shared codes, each code being a concept under examination. In applying this method we systematically familiarized ourselves with the interview transcripts and proceeded to generate initial codes across the entire dataset. The use of the FMT thus provided quantitative insights on the content of the interviews as a whole, sharing the experience of contributors on the SatNOGS development process.

Collaboration core and periphery, generalists and specialists

The CM in Figure 3 records 148 distinct contributors across 39 elements of the SatNOGS codebase. It provides a relative position for each contributor, knowledge that we also used in the interviews step. Reordered by applying the Hamming-distance, the matrix is observed to take on an L shape. At the one end we observe contributor C1, who touches 34 elements. At the other end we see 101 contributors touching exactly one. The boundary between collaboration core and periphery can be drawn at the first appearance of a single-element contributor. To facilitate the reading of the CM, we added two data points: the number of contributors per element (on the upper side) and the number of elements per contributor (on the right hand side).

As a sensitivity check in order to check whether the pattern depends on the exact cutoffs, we inspected the full row-sum distribution (see Table 3). The substantive pattern remains stable across alternative thresholds. That is, even if the periphery is expanded to include contributors touching one or two elements, it still accounts for 124 of 148 contributors. At the other end, contributors touching seven or more elements remain limited to 11. This supports the interpretation of a broad low-breadth periphery and a thin high-breadth integrative group.

Core and periphery can easily be distinguished by looking at both the two added data points. Specifically, the multi-element block (C1-C21) constitutes the SatNOGS collaboration core and the remaining contributors (C22-C148) constitute its periphery. As shown in Figure 3 peripheral contributors act on elements gathering ten or more contributors, while core contributors act on elements that gather 8 or less contributors.

To distinguish between generalists and specialists across the two parts, we classify contributors by participation breadth, i.e., the number of elements to which they contribute. Participation breadth is unevenly concentrated across elements as well as across contributors. For instance, the decoder element (E31) is the single largest receptor of contributions, with 58 distinct contributors, the majority of whom appear nowhere else in the CM. The data related elements (E9, E35, E36, E37) and the radio-related elements (E34, E39, E28, E23, E22), on the other hand, feature contributions from the core.

These two distinctions enable the classification of contributors as shown in the Table 4.

The core generalist set is constituted by contributors C1 to C4, C6 to C10, C15 and C16, all active in seven or more elements. Core generalists (in red in the CM) are characterized by wide-breadth contributors. The core specialist set, on the other hand, is constituted by contributors C5, C11 to C14 and C17 to C21, all active in two to six elements. Contributions in the latter set are restricted to fewer elements, usually a single major function of the system embodied by a few elements. The radio specialists C19 and C20 for example work almost only inside E39 and E34. In the core, elements and contributors are closely intertwined, providing a picture of multiple contributors engaging across multiple elements.

In parallel, within the periphery overall contribution is much narrower. On the one hand, the periphery generalists (C35 to C41, C46 to C51, C70 to C73, C81, C92 to C98 and C108) contribute to a similar amount of elements as the core specialists. The former serve the function of tying together elements of the periphery without belonging to the core. On the other hand, the single element majority are labelled periphery specialists and marked in green in the CM (C22 to C34, C42 to C45, C52 to C69, C74 to C80, C82 to C91, C99 to C107 and C109 to C148). This latter set does not contribute to any other elements, indicating an extremely focused expertise. The decoder specialist C123 for example, confines all contributions to satnogs-decoders (E31) and touches no other element.

Since core specialists and periphery generalists have a similar amount of elements they contribute to, we marked them both with orange.

A methodological limitation of the CM is the case of different individuals contributing under a single account. Such is the case of the satellite mission team we interviewed, where the CM lists only one contributor, yet, they express a collaboration between two individuals.

Another interesting finding, which initially emerged in our research as a misunderstanding, is the fact that the organisational core of the LSF and the collaboration core of SatNOGs are not identical. For instance C0 is recognized as an LSF volunteer by the organization, yet he is not a SatNOGS core contributor in the CM. Instead he contributes to the project in ways which remain important from the perspective of the LSF, without contributing to the software. We thus assigned him the designation C0 as he has no row in the CM.

Framework method table axes: interview-derived findings

The FMT shown in Tables 5, 6 show the outcome of our analysis of the interviews based on the emerging categories, that can be synthesized in the following axes:

Community Challenges and Contribution Barriers met by contributors in joining and participating in the development of the project.

Modes of Contribution & Ecosystem Roles. The qualitative findings echo the distinction seen in the CM between specialists and generalists, while providing more evidence on the distinction between paid and unpaid contributors.

The breadth of contributions

The dependencies between the different contributions.

Community challenges and contribution barriers

The first axis concerns the friction a contributor meets on entering the project. von Krogh et al. (2003) name such friction “contribution barriers,” the costs that complex code and strict protocols impose on anyone joining an existing project. As indicated by the interviews, in the SatNOGS collaboration case, this friction is due to two reasons: the absence of a published roadmap and the difficulties with the exact procedures of joining the community as a novice contributor (joining script).

The absence of an externally visible roadmap was raised in 10 out of 11 interviews, making it the single most consistent complaint we recorded. Apparently, this absence is felt across the whole community. However members acknowledge the existence of internal milestones that are part of the codebase the elements exist in. These milestones are discussed during weekly meetings. Yet, LSF members admit that comprehensive long-term roadmaps are not being effectively communicated to the broader community. For example C2 describes the consequences as an “unconnected parallel development” by contributors who cannot see the LSF developers’ internal plan. This fragmentation illustrates Gawer and Cusumano’s (2014) outline that identifies the concept of “roadmapping” in the world of technology as a means of communication. This communication is used by platform leaders to align external contributors and furthermore to prevent conflicting development. When this communication is missing, coordination breaks down. Because the periphery is less aware of the project’s trajectory, volunteers invest significant time on contributions that then get stalled or rejected. C49 reports that well-prepared changes to code can, in extreme cases, “lay around for, let us say, six, seven, eight months” before review.

The joining script challenge was raised in 6 out of 11 interviews. Every community has some rules and procedures according to which a contribution can take place. As emerged from the interviews this procedure in the SatNOGS community presents peculiarities, which may feel unexpected to the novice developer. The specific rules are described in the documentation, with details that can be omitted by new members. For instance, C123 had one of his early contributions rejected because he had not signed off on the commit. The “sign-off” is a procedure necessary for contributions to the SatNOGS project yet absent in other projects. Another contributor, C51, said: “There is this annoying ‘sign off’ which cannot be done via gitlab’s web-site. (…) Sometimes I feel like gitlab takes up more of my time than the contribution itself.” Nonetheless, such peculiarities embody a specific vision about the contribution of this community. Namely, signing off contributions is considered an important feature of collaboration, as contributions can thus be traced and monitored throughout the entire process of development. Around half of the interviewees mentioned having difficulty with the joining script (6 out of 11 interviews), but its effect concentrates on first-time, single-shot peripheral contributors, exactly the population the CM shows as 68.2% of its rows.

Yet, despite the tensions, the distributed governance mechanism of the community, along with its open-source principles, appears to be offering it the capacity to answer a greater challenge, i.e., manage diversity and complexity (Ostrom, 2010) within the specific contemporary multi-actor expansion of the space industry (Affonso, 2026). The community governance mechanism thus provides a possibility for different levels of engagement, ranging from single-element to generalist contributors to participate in the development of the system.

Modes of contribution and ecosystem roles

The second axis sorts contributors by character as induced by the specific mode of contributing. Four categories emerge: the first two echo the findings already identified by the analysis of the CM: specialists and generalists. The other two echo literature about the distinction between paid and unpaid contributors.

As we have already seen, contributors can be distinguished as specialists and generalists according to the number of different elements to which they have contributed. As already discussed in the introduction, von Krogh et al. (2003) describe a division between specialists, who tend to focus on one or two specific modules, and generalists, who spread their participation across modules to ensure architectural integration. The specialist and generalist split is the most uniformly endorsed distinction, appearing in all the interviews in the FMT. This stance was expressed by interviewees themselves, either when asked about their own contributions or when asked about their understanding of other elements of the system. One specialist, C72, said: “I work mainly in Network and DB. That’s where I started, that’s where I stay. So I’m purely a programmer, a developer (…) I’ve been a bit consistent in that part only.” On the other hand, the generalist C2 said: “We’re talking about a series of people (…) they are basically in the Venn diagram, they are at the center of all the groups that exist.”

Separately from the specialist and generalist categories, Lerner and Tirole (2002) further described the coexistence of paid developers and unpaid volunteers within one project. Both distinctions are present in SatNOGS. The paid/unpaid distinction was reported in 10 out of 11 of interviews. As emerged from the interviews, paid and unpaid contributors carry out different kinds of tasks. Paid contributors tend to engage in the development of elements that sustain the entire system (e.g., element E36 and related data handling elements), while volunteers contribute mostly in elements of the periphery, for maintenance and quality assurance purposes. The paid and unpaid distinction is clear for the core members themselves. Contributor C72 said “Look, because I’m also paid, I’ll basically say that as paid contributors (…) because there are paid and unpaid ones, let us say, so that’s the terminology.” Paid and unpaid contributors mix freely along the specialist-generalist axis.

As already mentioned, there is a difference between the collaboration core as identified from the CM and the LSF members, which are also called “core” or “crew” in the field (the list of core LSF “crew” is available online: https://www.libre.space/about/, URL visited on July 11th, 2026). The latter is constituted by 41 paid and unpaid members, 24 of which actually contribute to the SatNOGS software. In the interview with SatNOGS co-founder, the distinction between paid and unpaid was reported as “around 22 employees and about the same amount of unpaid LSF core, around 40 all together.” A more accurate indication of paid and unpaid contributors in the CM is not possible as this distinction is currently not public.

Nonetheless, we were able to cross-reference data about the LSF members contributing to the SatNOGS software, by comparing the names of the “crew” to the data of the CM. Thus, C1, C2, C3, C6, C8, C9, C10, C12, C16, C17, C18, C19, C20 contribute to the SatNOGS core, while those contributing to its periphery are C26, C47, C65, C72, C73, C80, C93, C94, C97, C136.

Moreover, we see that the LSF members are equally dispersed around the two different parts of the system (13 contributing in the core, 11 in the periphery) which echoes what interviews have indicated, i.e., that the organisation supports the system as a whole.

Contribution breadth

The third axis looks at how much of the system each contributor works on, further specifying the distinction between generalists and specialists, providing insights on how this distinction is experienced in the project. Similarly to what Mockus et al. (2002) have found for the Apache case, our interviews as well as the CM show a core team of both volunteer and paid contributors with contributions to a wide range of elements. Context for this is provided by C9 who states: “There are people who deal with specific things and there are people who deal with them in a more general form. Both are acceptable.”

Evidence from the interviews also fits the description that the periphery of the collaboration is characterized by narrow contributions and weak ties with other contributors. As we have seen in the CM, those contributors specialize most frequently in a single element or, under circumstances, in closely related elements. The case of E31 contributors is very characteristic: C2 calls external decoder contributors (E31) “fireworks,” further elaborating that “they will write code, do one thing, and then hide, disappear.” For instance, C123, verified what was already recorded by the CM, i.e., a single element contribution. As already mentioned, we found this large peripheral population empirically difficult to contact, which suggests that its representation in the CM mirrors the real life relation the decoders have to the SatNOGS project. Nonetheless, our qualitative insights about the periphery rest on very few voices from that part, thus they lend themselves to interpretation.

Dependencies between elements

The fourth axis looks at how different elements depend on each other to fulfill a function, as well as the ways in which LSF tries to reduce those dependencies. Such dependencies are recognized by the interviewees, who mention them in 9 out of 11 of interviews. C9 for instance brings attention to the interdependency of data-related elements (“things we do in the DB can affect the network, since the network uses the DB’s API; and things we do in the network can affect the client”). C20 reports that a planned change to one element has to wait until some changes to another are completed (“[a change in the radio elements] may be held back because there is no one in the network or client to adapt to it”).

On the organizational side, some interrelations are purposefully cultivated: the LSF paid contributors operate as a group of maintainers. They hold weekly meetings and provide internal chat rooms. These meetings help to coordinate the development happening on the various elements. Yet, there are also efforts to reduce dependencies between elements and corresponding contributors. Currently, as reported by C19, C20 and C0, the team tries to separate the E38 (client element) from the radio elements (E39, E28, E23, E22 and E34) by means of a containerization of its features. C19, in particular, explains: “We separated our components and re-made them in Docker, so with this change we also wanted to separate the client part from the radio part…” This is the least consolidated of the four axes, with 5 out of 11 interviews covering it, and reflects an in-progress organizational move rather than a settled property of the system.

The literature on open-source collaboration is divided on two approaches on how distributed work coheres. On the one hand, there is a theoretical approach which treats extreme modularity as the engine of participation, where contributors layer independently motivated tasks one atop another with absence of coordination (Howison and Crowston, 2014; Baldwin and Clark, 2000). On the other hand, there is the empirical approach, where studies describe a small tightly coupled core producing an overwhelming share of new functionality inside the project (Hergueux et al., 2025; Nakakoji et al., 2002; Mockus et al., 2002). Our research, on the SatNOGS software, contributes to the related literature by using a combination of such approaches. Specifically, we combined quantitative and qualitative methods, i.e., the Contribution Matrix consisting of 148 contributors across 39 elements with 11 targeted semi-structured interviews. Results suggest that the SatNOGS software sustains a globally distributed network of satellite ground stations (Shah, 2006), in which extreme modularity accounts for 68.2% of the contributors in the single-element periphery of the software system, while a thinner and intertwined layer of cross-element contribution holds the systems’ operation.

Furthermore, our study revealed ways in which challenges related to the multi-actor environment of the New Space (Affonso, 2026) and the attribution of individual contributions in open-source space projects (National Academies of Sciences, Engineering, and Medicine, 2018) could be addressed. In our case, rather than an opposition between peer-production and organisation (Benkler, 2017), we observed a synergy (Howison and Crowston, 2014; Shah, 2003; von Hippel and von Krogh, 2003; von Krogh et al., 2003) which had the particularity of unfolding within the framework of open-source.

Community challenges as the live tension of the project

It is noteworthy that the obstacles that surfaced most consistently from the interviews appeared to be procedural rather than technical in nature, from the point of view of the project’s own contributors. The single most thoroughly elaborated complaint was recorded to be the absence of a roadmap that is publicly visible to contributors. This was articulated both by paid members and volunteers. Lerner and Tirole (2002) anticipate this dynamic when arguing that what keeps a community together is a credible “vision.” In the broader context of technology ecosystems, technology roadmapping may be framed as a communication lever that platform leaders use to align external contributors to a common development path that prevents surfacing of conflicting visions or code (Gawer and Cusumano, 2014). In SatNOGS the interviews reveal that this vision exists to a degree internally and yet is not published in any meaningful way to the periphery. Because open-source projects tend to lack top-down project management, tasks are often deferred indefinitely until an individual tackles them independently. In SatNOGS it is this lack of a long-term external roadmap then, that exacerbates division between the generalist core and the specialist periphery. This generates a review bottleneck akin to the one identified by Mockus et al. (2002) in which a smaller core becomes overburdened with integration.

Issues related to the particular joining script (Fronchetti et al., 2023; Santos et al., 2025; von Krogh et al., 2003) make participation for newcomers challenging, yet assure an accountability that helps the contributions become manageable (Lerner and Tirole, 2002).

Collaboration among paid and volunteer contributors

If we move inside this procedural envelope, the social topology of SatNOGS departs in a marked way from the known and canonical open source arrangement. Libre Space Foundation reportedly employs around twenty two paid staff members, while treating approximately the same number of long term volunteers working as the “organisational core of the LSF” and granting them access to internal channels and to project information at a comparable level (interviews with contributors C2, C80). This type of composition does not match to the volunteer-led picture that the early OSS literature describes (von Hippel, 1988; von Krogh et al., 2003), and it does not correspond either to the corporate sponsored model where paid developers coming from a single firm dominate within the codebase (Lerner and Tirole, 2002; Mockus et al., 2002). It rather resembles a hybrid form developed by Shah (2006), in which paid and unpaid contributors function within a shared governance while having different but also compatible incentives. Yet, as indicated by the comparison of the CM with the interviews, the organisational core of the LSF is distinct from the collaborative core of SatNOGS, as the SatNOGS project and the LSF constitute two different entities with needs and goals which aren’t always the same. C9 in his interview states: “[there are] many things to deal with, many perspectives to be had as well. Some [features] we pursue more actively, some less so, or some are more actively pursued by the community and some are more actively pursued by LSF.” Our interviews indicate that the contributors themselves recognise the distinction and put it to use in practice, with paid and unpaid functioning as constituent categories (C2, C72, C16, C0). This practical division of development participation however, does not follow the payment status in a neat way. Hence, beyond the distinction between paid and unpaid, a potentially more influential one seems to be between LSF members (both paid and unpaid) and the others. LSF members act on both core and periphery of SatNOGS collaboration, ensuring coherence of the entire project. Thus, a complementarity is observed between the contributions of the community members (von Hippel and von Krogh, 2003) and the LSF members.

The distinction between specialists and generalists

The second cross-cutting distinction is the finding of separation between specialists from generalists, which as shown in the CM is applied both in the core and the periphery of the SatNOGS collaboration. This finding is also evident across all interviews and is coherent with the theory of specialisation within open-source communities (von Krogh et al., 2003). Furthermore, the specialists operate exclusively in subsets of the elements that depend on each other.

On the one hand the SatNOGS core-specialists maintain critical functions of the system. Examples include the radio-related elements with contributor C20 as a maintainer, and the data related elements with C72 as a maintainer. On the other hand, peripheral specialists, such as the “decoders” (E31 in the CM) only contribute to the part of the system relevant to one function. In the case of the “decoders” these are contributors that usually support a specific satellite mission, which produces the corresponding data to be decoded. The category in question also includes amateurs who treat the authoring of a contribution in this element as a challenge or pastime.

Core generalists are highly important to the system in the context of facilitating integration of a large part of the elements. C9, for example, traces a personal trajectory that moves across multiple elements. Peripheral generalists bind the different elements of the periphery together, differentiating themselves from single-element contributors.

The contributor periphery is characterized by what interviewers have deemed the “decoder phenomenon,” which is also visible in the CM. External mission teams and amateur operators may write a decoder for a satellite, and never return to the project to contribute to other elements in any manner that is visible in the contributions. One interviewee describes them as fireworks “they will write code, do one thing, and then hide, disappear” (C2). This is corroborated by the accounts of the satellite team we interviewed (C123) and our own difficulties in getting into contact with this very large group of contributors, in spite of the sheer number of discrete contributions. It appears that decoders contribute to a motivationally independent task with no need for sustained coordination, beyond following the contribution guidelines for the element in question. Furthermore 68.2% of SatNOGS contributors in the contribution matrix conform to that prediction. This presents a contrast to Howison and Crowston’s (2014) theory of collaboration through open superposition. Open superposition describes how independent contributors each complete a small and self-chosen task on their own. These contributions simply stack on top of one another without any specific coordination.

The remaining 31.8% follow a different logic which can be described as “intertwined collaboration” (Chrysos and Appio, 2024). Core contributors engage both in the development of peripheral elements and core elements, the latter being exclusively contributed by them. These consist of contributions that cannot be layered superpositionally because the technical dependencies between the elements in question force a coordination cost that the extreme-modularity model leaves unaccounted for.

Beyond modularity: intertwined collaboration

The degree of intertwined collaboration necessary aligns with the increasing complexity and inter-operation of the dependency chain. Intertwined collaboration (Chrysos and Appio, 2024) includes tasks such as coordination work, integration work, boundary-spanning activities, and systems maintenance. In all cases, it requires a collaboration that goes beyond a single element, spanning through different parts of the system. Thus, it requires broader knowledge of the system than that possessed by specialists and single-repository contributors, as well as the development of stronger collaborative ties among project contributors. This pattern is particularly evident in the SDR signal path (E39, E34) and the data layers (E36, E37, E38), where the decoders and dashboards are effectively positioned downstream of these components. Multiple contributions across the entire length of the dependency chain are made by generalist core contributors, whereas contributions limited to only specific aspects of the core-element such as the data layers can be classified as specialist contributions. Interviewees describe the chain in operational terms. Interviewee C9 states “things we do in the DB can affect the network, since the network uses the DB’s API; and things we do in the network can affect the client” (C9) and interviewee C20 states that a planned change in the radio layer “may be held back because there is no one in the network or client to adapt to it.” Baldwin and Clark (2000) predict that this form of cross-module dependency should generate a mirrored organisational structure. In our study this mirrored organisation is the LSF, facilitating a shared release cadence, weekly meetings and internal chat rooms. The architectural response, an in-progress Dockerisation of the client and a deliberate decoupling of client from radio (C19, C20, C0), corresponds to what MacCormack et al. (2006) deemed the construction of an architecture for participation, however this should be defined as an ongoing organisational move rather than a settled property of the entire codebase, as corroborated with the fact that it is one of our least consolidated findings (5 out of 11).

Implications of policy and coordination for open-source software space infrastructures

Taken together, the results show that SatNOGS is not only a community of paid and unpaid contributors, but also a governance arrangement for sustaining an open, infrastructure-grade space commons. The Contribution Matrix analysis reveals a large periphery of single-element contributors, where participation breadth remains narrow and contributions can often be made through extreme “modularity.” At the same time, they point toward a small generalist core of high-breadth contributors whose participation spans several elements and who carry much of the integration work. The interview insights add the organisational layer to this pattern. Specifically, they indicate that roadmap visibility, joining scripts, sign-off procedures, review bottlenecks, paid/unpaid coordination, and maintainer capacity all shape who can enter the project, how contributions are accepted, and where the burden of coordination accumulates. This is where the policy contribution of this research becomes operational. By identifying and mapping the collaboration dynamics of an open-infrastructure space commons, the SatNOGS’s case speaks directly to wider debates on the governance of open technological infrastructures (Ostrom, 2010; Benkler, 2017). Results suggest that 68.2% of contributors touch a single software element, while eleven generalists carry the integration load across the entire dependency chain. This internal structure of such an infrastructure sustains coherence (despite certain organizational challenges).

OSS-governance research shows that authority in open-source communities often emerges through contribution histories, recognised roles, access to internal channels, and negotiated responsibilities rather than through formal hierarchy alone (O’Mahony, 2007; O'Mahony and Ferraro, 2007). SatNOGS follows this pattern, but extends it into a digital-physical space wherein the coordination challenge is compounded by the coexistence of software repositories and a globally distributed network of physical ground stations. Findings indicate a partial divergence between organizational role and CM-position which is itself an empirical contribution: it shows that such digital-physical commons distribute consequential work across channels that no single instrument can capture in full, reinforcing the case for the mixed-method design adopted in this research. Crucially, the interview findings indicate that the main obstacles to sustain participation may remain procedural rather than technical, i.e., the absence of a concrete roadmap, sign-off friction that falls hardest on single-element newcomers, and a review bottleneck that concentrates gatekeeping in very few maintainers.

In relation to existing Space 4.0 policy debates, the SatNOGS’s case indicates that sustaining open-source space infrastructures requires governance support that extends beyond open-source licenses and technical access. In view of this, policy frameworks should focus on how integration work is distributed and rewarded in a way that the few contributors who carry coordination utilities are supported over time. They should also consider how the project can remain accessible to the large base of occasional contributors whose participation sustains its modularity.