GEOG 323 Reflection 1: What is Open GIScience?
This week we read articles by Rey (2009) and Singleton, Spielman, and Brunson (2016) discussing the role of open source in spatial analysis and geographic information science (GISc), as well as what it means for software to be open source and/or free. These readings, and our subsequent class discussion, pushed me to seriously consider these questions for the first time. I had previously thought of open source and free as interchangeable. The open source software I've worked the most with is QGIS, which is both open source and free, at least in the sense that it costs nothing to download. QGIS is also free in the sense that it's relatively easy to become part of the QGIS developer community and that you can easily examine other people's code as you learn how to write your own. However, Rey's and Singleton et al.'s arguments pushed me to think more critically about the distinction between open source and free, as well as how that looks in the specific case of QGIS.
Rey makes an interesting distinction between open source software being "'free as in beer'" and "'free as in speech'" (p. 199). Being "free as in beer" implies that anyone can download it at no cost, as well as that everyone has access to the source code for their own perusal and enlightenment. The "free speech" aspect relates to people's ability to modify and contribute to the source code base for the entire community of software users. Although I value this aspect of open source software and have personally exercised my so-called freedom of speech in the QGIS community, I had never really contemplated the distinction between these two freedoms before. Yet I agree with Rey that freedom of speech is "the more fundamental of the two freedoms," as "[b]y tapping into the power of user-led innovation it can stimulate the engagement of skilled attention so vital to the flourishing of successful open source communities" (p. 199).
Although Rey argues that "[t]he instructive and constructive functions played by open source software could be immensely helpful in addressing" the barriers to entry into GISc (p. 199), I think it's important to point out that achieving advanced freedom of speech in the world of open source is easier said than done. At the very least, it requires a level of investment that can be tough to achieve under circumstances where no one is getting paid to foster accessibility and inclusion. I've witnessed this paradox firsthand in the QGIS community. I started writing Python scripts for QGIS last summer in an internship, and this Winter Term I worked with Prof. Holler to develop a plugin with basic algorithms for Middlebury's introductory QGIS course. I've really enjoyed being part of the QGIS community and learning from other developers, whether from their responses in GIS Stack Exchange discussions or directly from their source code. The QGIS Documentation page and the PyQGIS Developer Cookbook provide a detailed look into the QGIS Python API, but the documentation can be sparse and difficult to interpret for the inexperienced developer (such as myself). Thankfully, individuals like Anita Graser and the folks at Open Source Options provide helpful tutorials to help lower the barriers to entry for novice QGIS developers. Still, I often hit programming snags where it's incredibly difficult to figure out what's going wrong with my code. Usually I can come up with a solution through extensive Googling and poring over the documentation, but it takes a lot of time and energy, and sometimes a code snippet from someone much more experienced than me who seems to magically know the answer. Opening the door to the QGIS Python API can be very confusing and overwhelming; while speech is ostensibly free in the QGIS community, there are still significant barriers to reaching the point of making meaningful and innovative contributions.
I don't mean to suggest that developing software should be easy, or that a novice user should be able to write their own algorithms right away. However, contributing to an open source project is both rewarding and educational, the latter of which is, of course, particularly important in an academic context. Expanding the community of open source contributors necessitates enough resources and documentation to ensure that novice developers feel supported and know where to look for help. Rey points out, however, that the incentives of academia tend not to reward researchers for contributing to open source projects. Yet robust contributions to open source code and documentation by academics can and should play an important role in the growth of these projects and students' ability to engage with and contribute to them. Accordingly, academics should receive credit and praise for helping develop open source projects. Truly open access to source code and documentation is crucial in ensuring genuinely free software that not only costs nothing but also empowers as many people as possible to engage with and contribute to the project.
Singleton et al. echo this call for transparency and access in the field of GISc in particular. The argument that GISc research should be fully reproducible through published code and publicly available data was a new one for me. I hadn't really considered that it might be possible, let alone that I would have the capability, to reproduce GISc research. But if other types of scientific research are meticulously documented and therefore reproducible, why not GISc? I agree with Singleton et al. that a model of truly open GISc would support integrity in research; furthermore, having access to full sets of code and data from academic papers could prove hugely valuable for educational purposes, as students would be able to see how the tools they were learning can be applied in real-world research settings. Open GISc may be, as Singleton et al. put it, "embryonic" (p. 1507), but I'm excited to see how the growth of this paradigm, alongside the explosion of the open source movement, will transform the ways in which we learn, understand, and advance all types of spatial analysis.