The article aims for examining the ‘technological stasis’ of the data structure in OpenStreetMap – the successful global collaborative geodata project devoted to ‘create and distribute free geographic data for the world’. Digital structures are strongly influenced by continuing stagnation. This technological stasis – the lack of change in technology – influences data in various ways, as demonstrated by the intensive discussion of the issue by computer scientists and software engineers. However, existing research describing stagnating software is often technic centred and fuzzy, while critical research is barely considering issues of technological stasis in the digital context at all. Therefore, this paper aims for enriching this body of knowledge in order to shed light on aging data structures. I reframe technological stasis with a social-constructivist perspective – using the approach of Social Construction of Technology – especially with the concept of technological frames. Based on the case example of OpenStreetMap, my findings suggest that the data structure – and its stasis – is the outcome of competing understandings and perspectives, shaped by power asymmetries. Although the data structure did not significantly change for more than 10 years, I demonstrate that this is not because of a lack of motivation, nor technological difficulties of carrying out such changes. The technological stasis is rather rooted in the dominant position of few project members who are able to change the software design; it is their perception of the project that defines how data should be stored and what features are dispensable.

Introduction In the wider arena of Science and Technology Studies (STS), technological dynamics, innovation and the emergence of new technologies are traditionally predominant subjects of discussion. For example, Bijker (2012) analysed the emergence of Bakelite, a predecessor of plastic material; MacKenzie (2012) focused on developments of missile guidance systems in the US military; Law (1987) examined inter alia the innovation of sailing ships in the context of the colonial expansion of Portugal. All of them share the understanding that – to explain technological change – we have to scrutinize stability, obduracy and continuity of technological artifacts. Hommels acknowledges that ‘[…] it comes as no surprise that technology’s obduracy and its effects on society have been a major concern in technology studies, if not the prevalent one’ (2005: 329). However, when turning to current discussions dealing with emerging technologies, the exploration on stagnation seems missing. Especially in the context of digital technologies, the lack of a theoretical discussion regarding technological stasis is striking. And yet, many software applications, algorithms or Big Data projects are mainly influenced by continuing stagnation. Taking the example of databases, old data structures are preserving outdated understandings and concepts, making it increasingly difficult for a project to adapt to new needs evolving in the broader environment. Furthermore, outdated data structures impede the development of other applications in the overall system, which build upon them, forcing them to compensate the deficiencies with cumbersome workarounds. This technological stasis is hardly a new issue, as it has been subject to software engineers in various studies (for example, see Bennett, 1995; Eick et al., 2001; Parnas, 1994). However, it has been mainly addressed from a problem-solving perspective (Chiang and Bayrak, 2006; Kim, 1997; Miller, 1998). As existing literature addressing stagnating software is often technic centred and critical research barely considers issues of technological stasis in the context of digitization at all, this paper aims for enriching this body of knowledge by shedding light on stagnating data structures. Therefore, drawing on the debates of critical data studies, software studies and the social construction of technology (SCOT), I will reframe technological stasis with a social-constructivist perspective – utilizing the concept of technological frames (Bijker, 2012; Hommels, 2005). The objective of this paper is to address technological stasis on the case example of OpenStreetMap (OSM). I want to approach this objective from two opposing perspectives: first, from an engineering point of view, I will discuss the phenomenon of legacy software and its impact on technological change. Thereby I will show the insufficiency of this approach. Second, I will take a social-constructivist perspective by applying the theory of the SCOT, and the concept of technological frames in particular. In doing so, I want to reframe this concept by showing that it is a question of social context and power when talking about technological stasis. The case example for this study is OSM, the ‘free wiki world map’ (OpenStreetMap contributors, 2017). I argue, that the data structure in OSM is the outcome of competing understandings and perspectives, shaped by power asymmetries. Although the data structure did not significantly change for more than 10 years, I will demonstrate that this is not because of a lack of motivation or willingness, nor technological difficulties of carrying out such changes. The technological stasis is rather rooted in the dominant position of few project members who are able to change the software design; it is their perception of the project that defines how data should be stored and what features are dispensable. In the following sections, I will first give an overview of existing literature regarding Open Source Software (OSS) and understandings of technological stasis from an engineering perspective. I then turn to the case example of OSM, illustrating the perception of technological stasis. Based on my empirical findings, I will demonstrate that there are in this respect contradicting voices in the community. To dissolve the contradiction between the different perceptions of the very same phenomenon, I introduce the concept of technological frames, based on the SCOT. Following this theory, I will then argue, that there are different social groups involved in technological development of the digital infrastructure, divided along the line of their technical skills and field of action. This division also marks the power of the group in the community: if the group with the technical skills for manipulating the data structure won’t see any problem with the existing infrastructure or won’t see the benefits of adapting it to new needs, no change will happen.

Research design For examining the technological stasis in OSM, I build on a multi-perspective approach by employing qualitative and quantitative methods. The qualitative approach utilizes a qualitative content analysis with a focus on content structuring (Mayring, 2010: 98). The data sources for this approach consist of eight semi-structured interviews, which were conducted via telephone and VoIP. The interview guideline includes questions regarding the general position and activity in the OSM community and the perception of and interaction with software, data structure and software development. The interviews were recorded, transcribed and anonymized. Furthermore, I examined 16 secondary interviews in ‘The Book of OSM’ which seeks to ‘[…] provide a variety of viewpoints […] of those important to the project’ (Coast, 2015: 2). Although the interviews weren’t conducted by myself, the content is valuable since the data is still ‘[…] slightly raw’ (Coast, 2015: 2). Additionally, I searched and examined OSM mailing lists and the wider environment of community communication, online project documentation and OSM conference data for software-related discussions and issues (see Table 1). The evaluation of the qualitative data is based on eight key themes which I derived from the theoretical framework and contextual focus. After a first reading of the data, I further differentiated them into more specific categories (see Table 2). In a second reading, I examined the data to assign fragments of data to according categories. These data informed my understanding of my theoretical framework and contextual focus from a qualitative perspective. Table 1. Data sources. View larger version Table 2. Key themes of the qualitative content analysis. View larger version The quantitative approach builds on an evaluation of source code repositories of OSM (see Table 1). I aggregated the code revision per month and person to illustrate the overall development of OSM software over time and the impact of individuals. Furthermore, I utilize well-established concepts of the computer sciences to describe the relation of actors with software artifacts.

Conclusion and discussion Although OSM is a very heterogeneous project with a diverse community, its software infrastructure shares significant similarities with OSS projects. Back end-related software development in OSM is, inter alia, driven by intrinsic motivators such as fun and enjoyment, while monetary benefits play a less significant role. Also, the structure of power, control and governance appear to be in line with OSS findings, as there is a core team of developer dominating software development. Regarding evolutionary dynamics of OSS, OSM is in a growing stage, which contrasts its technological stasis. This phenomenon of stagnating software is a well-known issue in the computer sciences, however existing literature addresses stagnating software often from a technic-centred or problem-solving perspective. By framing this issue with a social-constructivist perspective, I focused on social context and power. The SCOT, informed by Klein and Kleinman, is a useful framework for understanding technological change and stasis and how specific expertise can influence the perception of technological possibilities. Klein and Kleinman’s critique is beneficial for identifying crucial points in the process of technological development and how asymmetric access to resources can exclude groups from it. My results indicate that the technological stasis in OSM is rooted in a combination of the diverging perception and thus obduracy of the data structure and the access to the design process. While the largest group perceives the data structure as very obdurate because of their low inclusion into the web 2.0 frame, it is the same case for the smallest group, which is dominating the software development, though due to their high inclusion. The main group advocating change can’t access the design process, as it lies beyond their field of action. I described these results in the first level exclusion. Since SCOT is focusing on a group level, individuals in gatekeeping positions with a major impact on the overall system are easily overlooked. Thus, I introduced a second level in which I focused on individuals within the group of developers. My findings suggest that there are several developers in key positions who further paralyse the group of developers from the inside. But how did these levels of exclusions emerge in the first place? One of the major reasons lies in the do-ocratic decision-making, as it excludes a significant part of the community and thus their ideas for change. Furthermore, OSM’s driving forces for (code) contributions cause an adverse environment for fundamental technological change. A combination of suspicion towards external for-profit actors and monetization, a fear of damaging the community, the implicit interest in having power and control and a hobby-like motivation of fun and enjoyment is not an environment for constructive discussions or productive software development. This leads to another question: is this kind of environment still suitable for a project that has grown so much? Do-ocracy is a beneficial decision-making principle for a young and evolving open source project based on volunteers – it advantages rapid growth since there is no need for votes on specific software designs. But is this still the case for a project with more than four million registered users, who are mostly unable to carry out technological changes and thus are excluded from the design process? Similarly, should such a large project rely – in its core – on the voluntary work of very few people? Or did OSM reached the point, where the stakes are too high for do-ocracy and hobbyists maintaining the main infrastructure? Although it is difficult to find an optimal environment for software development in such a diverse and complex project as OSM, it seems inevitable to include all community members in the design process and take their needs into account.

Acknowledgements I would like to thank the anonymous reviewers as well as the editors for their helpful suggestions and comments.

Declaration of conflicting interests The author declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.

Funding The author disclosed receipt of the following financial support for the research, authorship, and/or publication of this article: The author was supported by a grant of the Hanns-Seidel-Stiftung and acknowledges support by Deutsche Forschungsgemeinschaft and Friedrich-Alexander-Universität Erlangen-Nürnberg (FAU) within the funding programme Open Access Publishing.

Notes 1

https://wiki.openstreetmap.org/wiki/Stats 2

https://wiki.openstreetmap.org/wiki/Stats 3

The first code for the database was contributed in December 2004. 4

The first mail on the mailing list was sent in October 2004. 5

The first code for an editor was contributed in April 2005. 6

The domain for the website www.OpenStreetMap.org was registered in October 2004. 7

It is notable that the decrease of code revision beginning in 2010 may also partly be caused by the successive change to another source code repository system. 8

https://www.openstreetmap.org/user/ThePromenader/diary/13610 9

For example see http://wiki.openstreetmap.org/wiki/Contributors_functionalities_wishlist, http://wiki.openstreetmap.org/wiki/User:Frederik_Ramm/Ideas_for_API_0.7 10

For example see https://lists.openstreetmap.org/pipermail/dev/2012-July/025256.html, https://lists.openstreetmap.org/pipermail/dev/2011-April/022313.html 11

https://blog.emacsen.net/blog/2018/02/16/osm-is-in-trouble/ 12

For example see https://lists.openstreetmap.org/pipermail/dev/2012-July/025256.html, https://lists.openstreetmap.org/pipermail/dev/2008-November/012463.html 13

http://wiki.openstreetmap.org/wiki/Editors 14

http://wiki.openstreetmap.org/wiki/List_of_OSM-based_services 15

https://wiki.openstreetmap.org/wiki/Stats 16

http://www.ostertag.name/JoergOstertag/index.shtml, https://compton.nu/about/ 17

https://lists.openstreetmap.org/pipermail/talk/2004-November/000078.html 18

http://wiki.openstreetmap.org/wiki/Mailing_lists 19

https://forum.openstreetmap.org/ 20

https://trac.openstreetmap.org/ 21

https://irc.openstreetmap.org/ 22

https://svn.openstreetmap.org 23

https://github.com/openstreetmap/ 24

https://trac.openstreetmap.org/ 25

http://tomchance.org/2010/07/16/political-philosophy-in-openstreetmap/, https://blog.emacsen.net/blog/2018/02/16/osm-is-in-trouble/