I recently published the article “The social construction of technological stasis: The stagnating data structure in OpenStreetMap” in the journal “Big Data & Society”. In this article, I present my latest research on the core of OSM’s software infrastructure – the data structure. Thereby, I focus on the development process of this central part, respectively the lack of change in the past ten years. Although I start the article with concepts and approaches of the computer sciences (legacy software etc.), I reframe the issue of stagnating software with a social-constructivist approach: the social construction of technology (SCOT). SCOT enables me to consider social influences, relations and power asymmetries for examining the development processes of OSM software. I conclude the article with the finding that the lack of change “[…] 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” (2018, 1).
The article drew some attention in the OSM community, as it was discussed on the “talk” and “science” mailing lists and reddit. Additionally, I received several e-mails with questions and concerns regarding the article. I want to address some of these issues in this blogpost. It is important to me that I am not intending to discredit any individuals or OSM in general. I am myself an active contributor and advocate of free and open geodata and the OSM project in particular. Thus I hope my findings won’t offend any OSM contributor and rather encourage discussions regarding software development in OSM.
- Is the shaping of OSM’s software insignificant in comparison to the agency of users?
In my article, I argue that our (digital) tools influence our actions: the shape or design of a tool can facilitate some actions and impede others. This may be very implicit and trivial in some cases, but it becomes significant on a large scale. Thus it is important to note that the design of those tools have (social) consequences whether they are intended or not. Admittedly, it is often hard to imagine alternatives to the status quo (especially in the case of the data-model), which makes the relevance of the design of tools appear unimportant. But this is because we are children of our time and we can hardly think beyond our discourses.
Another argument of mine is, that the data-model, respectively the database, is a very central element of the OSM software infrastructure. Nearly all parts of OSM’s infrastructure build upon it – be it the editors, renderers or other interfaces. This is also the reason why I’m focusing on it: with its high centrality, it becomes an essential part of OSM’s software ecosystem.
- Are my statistics/findings based solely on the top 20 contributors?
My empirical analysis is based “[…] on a multi-perspective approach by employing qualitative and quantitative methods” (p. 3 f.). I evaluated mailing lists, I checked blogposts, I talked with people and I analysed the code repositories (see table 1). I built on this research design in order to balance out the weaknesses of a mere quantitative or mere qualitative approach. For example, a quantitative evaluation of code revisions has limited validity, since a single code revision could be a major contribution or some minor spell-fixes. However, by interviewing involved actors and evaluating the mailing list, it is possible to determine significant contributions.
- What is my understanding of stagnating software?
A member of the OSM community argued, that stagnation on the level of the data-model is less significant, since OSM’s software infrastructure is evolving on the upper levels. In my article, I argue for a contrary view: already in 1994, Parnas noted in his article “Software Aging”, that aging software begins simultaneously with stagnation of central parts and the addition of new features in the periphery. I think this pattern is the case in OSM. Additionally, my argument is based on the perception of OSM’s software by the community as well: several voices raised concerns regarding the stagnating core of OSM’s software (for example, see https://blog.emacsen.net/blog/2018/02/16/osm-is-in-trouble/).
- So what am I concluding?
In the paper, the argument that the stakes being too high for the current state of software governance is based on the observation of OSM’s stagnating data-structure and its contradictory perception. In the paper, I further examine the reason for the lack of change. My data indicates, that this is a systemic problem of software development in OSM: I name two levels of potential exclusion. Thus I conclude with the open question whether the system-in-use is the appropriate system; or whether the project has matured and grown too much without adjusting its software development process.
Another aspect of my criticism on software development in OSM – which was not comprehensively addressed in the article – is rooted in the limitations of do-ocracy. Do-ocracy is a very suitable decision-making principle for small specialized software projects, which are most common in the open source context. Per definition, do-ocracy is made for conditions, in which the stakes are low. The community wiki (https://communitywiki.org/wiki/DoOcracy) mentions inter alia the organization of food for the Burning Man Event as an example. Do-ocracy is also used public participation in the conventional political sphere: A common use-case in the context is the restructuring of playgrounds. These are all scenarios in which a complete failure has no major consequences. Thus I asked myself, if this is also the case in OSM. OSM has a huge community, which invests countless hours of the spare time – not to mention the projects which build upon or use OSM’s data or infrastructure. This is a lot of responsibility which is maybe too much for a decision-making mechanism which is made for low stakes.
In summary, my findings are based on the analysis of several empirical sources and evaluated from a specific theoretical perspective; other researchers or individuals with another perspective or approach may come to different conclusions. Also, it is self-evident that I am not infallible. Nevertheless, I claim that my line of argumentation and my methodical approach transparent and coherent.
I hope I could clarify some concerns and make my point clear. I am happy that my article was noticed and discussed in the OSM community and I am thankful for criticism and comments. If there are any further questions I am very happy to answer them.
Parnas, D. L. 1994. “Software Aging.” In Proceedings of the 16th international conference on Software engineering, edited by IEEE Computer Society Press, 279–87. Los Alamitos, Calif.
Plennert, Matthias. 2018. “The social construction of technological stasis: The stagnating data structure in OpenStreetMap.” Big Data & Society 5 (2): 205395171879059. doi:10.1177/2053951718790591.