Posted by r.silva on 13 May 2016 - 9:49am

By Caitlin Bentley, Postgraduate research student, ICT4D Research Centre, Royal Holloway University of London.

This is the fifth in a series of articles by the Institute's Fellows, each covering an area of interest that relates directly both to their own work and the wider issue of software's role in research.

Information and communications technology for development (ICT4D) is a relatively contemporary multi-discipline, and continues to evolve. Generally, ICT4D comprises the application and development of ICTs to achieve social and economic development goals. Heeks (2010) wrote that ICT4D researchers need to approach research problems from a tri-disciplinary perspective: computer science, information systems and development studies. Additionally, ICT4D is fundamentally about human and sustainable development, and as Unwin (2009) has previously argued, researchers must prioritize the development needs and wants of the poor and marginalised people. ICTs are not a silver bullet by any means.

The roles of ICT4D researchers are to act as intermediaries, critics and advocates, and we draw ICTs from within our tool belts to engage in the politics of social, economic and sustainable development processes. Nevertheless, technological solutions to development problems can be beneficial if they are built upon existing social and political systems, if they are sustainable and scalable, and if they engage poor and marginalised people as active participants in development processes. Balancing all these dimensions simultaneously is quite complex, and it is from this perspective that I approach the topic of software sustainability. In this post, I explore what software sustainability means to me as an ICT4D researcher, in order to further substantiate the need for greater software sustainability support in UK higher education. Secondly, I argue that different software contexts impact the scope of software sustainability in highly political and resource constrained environments. I use three different examples to shed light on how software sustainability, as it is currently conceptualised, fails ICT4D. The article ends with a summary of three recommendations for software sustainability.

Software sustainability and my journey as a pracademic nomad

Intellectually, I developed a curiosity in learning and human computer interaction as a technology capacity building volunteer in Morocco, and then in Mozambique. I was fascinated by the memory representation schemes of a co-worker, who was trying to work through the abstract (and foreign) concept of a file system on a computer. We would enact various scenarios of copying and pasting files in real life, we would draw file systems, we would talk about them, we would explore by clicking around, but there was just no possibility that he was ever going to represent a folder in a file system as a general concept in his memory. Each folder was unique to him and symbols that looked the same meant that he did not differentiate or navigate between them easily. It was this experience that led me to depart from my academic roots in computer science to study educational technology because I wanted to explore how humans learn, and subsequently how I could improve computer technology to make it easier to understand, and more relevant for people like my former colleague.

I was introduced to learning and design theory at a time when significant developments in social computing were opening new worlds of possibilities in terms of learning and collaborating. I became interested in constructivist education and social computing tools for what I thought could have enormous impacts on empowerment, community building and subsequently, learning outcomes. For instance, I created websites where citizens could learn how to contact their Member of Parliament about issues that were important to them, and for volunteers to congregate and organise events in their own communities. I researched social tagging for knowledge sharing and networking, and explored how to adapt constructivist learning design for public engagement.

Oscillating between academics and practice, I later worked as a project coordinator for a communications capacity building project. I researched and supported 17 civil society organisations (CSOs) in West Africa in order to connect them to the Internet, and to facilitate online collaboration in areas such as leadership and policy influence. For this project, I followed a well-accepted design methodology that took into account the various technical, human and political contextual factors that influenced the project context; yet, my online collaboration design project was still largely unsuccessful. The reasons for failure included a lack of willingness to change existing activities, lack of power to change wider structural practices (such as reporting requirements), and a lack of motivation to engage in the design process. Throughout the project, I was beginning to see that the practical day-to-day tasks that preoccupy CSO workers were of much greater importance to them than the serendipitous collaboration possibilities that I was intellectually attracted to. This is essentially an example of the webs of experience that ICT4D researchers are inspired by, yet begins to demonstrate how we are also faced with real dilemmas when confronted with the truth that sometimes we, and ICT solutions, are not wanted or needed.

I was not, however, ready to give up on the transformative potential of ICT to seriously change the organisational landscape, but I recognised that I needed to build a case for the positive possibilities of ICTs. I also needed to understand all the ways in which organisational workers did or did not want to change, so that I could convince them that ICT could help them. The initial premise of my PhD research was therefore to leverage design research as a means to change development practitioners’ beliefs and attitudes towards technology as well as to position them to accept and influence technology innovation. The capability of practitioners to guide innovation is important because people living in developing countries are not regularly targeted users of mainstream software. Within developing country contexts, people are more likely to have a mobile than a computer, there are varying levels of connectivity, and heterogeneous cultural practices and languages. In other words, mainstream software developers in the Silicon Valley probably do not understand what is wanted and needed in Africa. Whilst there are growing communities of developers in developing countries, there is still a need for broad based engagement amongst organisational workers to get involved in the co-design of tools they could benefit from.

Finding an institutional and departmental “home” for my research turned out to be quite difficult. For example, a computer scientist would not be awarded a PhD for merely researching how people change and apply ICTs to real-world problems. At the same time, software is integral to my research interests, and many social science-based supervisors replied saying that they could not supervise me because they did not have the expertise to address the software side of my research. My research became much more about understanding the role of ICTs in mediating relationships than about influencing how practitioners design and use ICTs. I see this as valuable in its own right, but it highlights the gaps of universities in supporting PhD students who wish to design and develop software not as a product of their research, but as a tool for experimentation within action research contexts. Simultaneously, as I have pointed out in this section, there are aspects of each research discipline (or multi-discipline) that requires expertise and exploration in collaboration. Software sustainability concepts could therefore mean a great deal to developing supportive long-term environments for researchers in ICT4D, but the next section explores how and why we must also contemplate what software sustainability means in our own nuanced ways.

Tensions surrounding introducing software sustainability as a concept in ICT4D

At the Software Sustainability Institute, we are dedicated to making software a bonafide research output, and we argue that good software practices create better software, which ultimately improves the reproducibility and reusability of research. ICT4D researchers that take a social-embedded view of technology (who are many) are much less concerned with the reproducibility and reusability of research in scientific terms. Instead, we believe that the meaning of software is only understood through its use in context, and that the people who use and create software can shape, and be shaped by it. Furthermore, extreme inequalities in global software production and use are shedding light on the need to examine how software perpetuates existing power imbalances and entrenching dependencies across the globe. This means that we are also concerned with understanding the dominating and restrictive conditions that software imposes on people in different places. Ultimately, this makes it very difficult to develop standard good software practices, because we will always place human development needs ahead of software sustainability needs. The next three examples highlight this tension.

1. Software sustainability and participatory or co-designed software

Winschiers-Theophilus et al. (2013) explored how to transfer co-designed software to other geographical contexts. The co-designed software was originally intended to document indigenous forms of knowledge in rural parts of Namibia. The preservation and communication of indigenous knowledge is incredibly important in development contexts, because top-down policies that neglect local systems and customs often fail miserably. In some countries, local customs and governance structures vary so much that governments need to have very detailed understandings across regions to make any headway, and more importantly, local people have rights to participate in the governance of their own communities. Winschiers-Theophilus’ research team has been quite successful undertaking a co-design process to document local knowledge in Namibia because they spent years immersed within the communities, learning about customary practices, their values and cultures. Now, they are curious to explore how they can transfer their co-design process to other communities and countries. Their article details how they have developed methods to experiment with this idea; for instance, they created a drawing game where community members draw a concept (cow, house, marriage, etc.) until another member of the community guesses the meaning correctly. In this way, the designer merely supports the community to design the knowledge representation scheme. The community can then use 3D models to build their own visual records that are relevant to their local customs and procedures. Having visual records has also been quite valuable to communicate with populations that are not literate. Considering each community has different concepts and representations of knowledge, the software had to adapt or change considerably in different communities. For instance, different communities within Namibia follow different religious and tribal customs, and now the team has also been asked to carry-out similar activities in Malaysia, adding in additional layers of complexity relating to language and geography.

Participatory and co-designed software represents a great challenge for software sustainability. Informally, Winshiers-Theophilius’ research team is willing to share their software, but they have not published it, and they are not quite sure what to do with the various forks of their software designs. The forks are actually what makes the software rich and valuable in each community. Furthermore, if they choose to support a network of communities that are responsible for maintaining and updating their indigenous knowledge banks, they must also be able to do so in a variety of languages. At some stage, the research team will likely have to make compromises in terms of where they spend their efforts, and they will need to balance how much they invest into improving a common platform versus supporting a network of champions that take hold of their software to benefit their own communities, such that local developers can maintain and improve the software. If the ultimate goal of ICT4D is indeed to prioritise the needs and wants of marginalised populations, it is difficult to build a case for investing in software at the expense of reduced utility at the community level. It is vital to build a convincing argument, one way or the other, that the resources required to build a supportive software infrastructure are necessary.

2. Software sustainability and local ownership

Open source software production and distribution models are usually the gold standard for software sustainability. Although there are numerous studies that have highlighted the benefits of open source software to support ICT4D processes, many researchers are questioning the principles and limits of open source as a ‘solution’ to software sustainability. Vallauri (2015) researched participatory video practices within agricultural extension programmes in rural Kenya. Vallauri started the research assuming that open source software would be the most sustainable for under-resourced farmers and community-based organisations because of the assumed low-costs and capacity to adapt software to local needs. However, Vallauri confronted typical open source software obstacles, such as poor documentation and difficult to fix bugs that left key features unusable. Additionally, where power outages were frequent, Linux distributions reacted very poorly. In one instance, an entire team was locked out of hardware that they relied on because an original implementer left without leaving proper documentation. Although this is arguably less of a problem with more standardised, proprietary solutions, in Vallauri’s case, true sustainability came through ownership, not open source software.

Ownership meant that mapping the local skills and picking software that is already in use by others is far more sustainable than opting for open source software out of principle or potential. Creating a supportive network around users and producers, and instilling sharing cultures and practices within communities was far more effective and sustainable in this case. Rey-Moreno et al. (2012) likewise confronted similar obstacles when selecting and developing wireless networking platforms in Latin American communities. The research group wanted to extend open source solutions because these were adaptable and aligned with their principles. However, the researchers required significant resources, learning and experimentation to adapt the existing platforms. Once again, ownership in terms of the power to implement and maintain systems proved to be of greater importance than the modifiability and cost of the software.

Whilst I agree that open source software will continue to breed a much needed software sustainability foundation, there is also a need to seriously consider how ownership, particularly when using proprietary and pirated software, is also a major part of software sustainability processes.

3. Software sustainability and cynical truths

The last example I present draws from my own research. Take for example the International Aid Transparency Initiative (http://www.aidtransparency.net/), which has made it possible to aggregate aid information across development aid donors in order to compare aid allocations to developing countries. 202 organisations-including multilateral donors, foundations, CSOs and governments-have published data to IATI since its launch in 2011. Since then, new software tools have been developed that enable Internet users to browse development funding and projects. For example, aid flows by sector, administrative costs, overhead costs, and recipient institution can be analysed in order to find patterns in disbursement that expose accountability problems like selectivity (funding countries for political purposes rather than need) and tied-aid (funding countries only if they accept to buy services and resources from the donor country). By opening up information and making institutional practices transparent, recipients, CSOs and taxpayers alike can monitor donor activities. However, I consulted a range of Web development companies that had contributed key Drupal modules and Web platforms to take advantage of this new transparent information. I found that CSOs and donors had been spending between £15 000 to £100 000 to create their own individual platforms.

When donors and organisations invest in separate websites and expensive infrastructures that fragment development data and information, it undermines development goals relating to partnership, harmonisation and coordination of aid that they are purportedly treating through the sharing of this information. There is a disastrous difference between cooperation and software sustainability here, because in many respects, the Drupal software modules were developed for wider use, thus respecting good software sustainability practices. Yet, had these organisations pooled their resources and committed to a joint information platform, copious monetary resources could have been used in a much better way. Instead this money has merely served the interests of the donor organisations rather than the poor and marginalised people that they intend to support.

Software sustainability has to contribute at the critical interface of advocacy and practice in this regard because we need not lose sight of the potential for software sustainability to free up much needed resources and to improve on research and practice, but this necessarily requires researchers and practitioners to call into question the policies and practices of governing institutions such as our universities and governments.

Last thoughts

Overall, there is a need for different disciplines to create their own nuanced versions of software sustainability, and in the case of ICT4D, this involves much more than developing best practices relating only to technical issues or the social aspects of technical implementations. Multi-disciplinary researchers, in particular PhD students such as myself, need greater institutional support in this area, as using software in research in a sustainable manner cannot be achieved within the short time-span of a PhD, and requires collaboration beyond a single supervisor.

I have also presented challenging dilemmas in ICT4D research relating to software sustainability, especially since our field relies on practical realities that are often highly political. Issues relating to software sustainability could potentially contribute to developing new and joint solutions to address common problems, by learning from other disciplines, and by creating ways to connect our research methods and results through working on software sustainability mandates. However, we have also learned a great deal in ICT4D that is important for software sustainability more generally. Namely: 1) we need to develop social-embedded and critical views of software in research practice and in our communities of influence; 2) the concept of software sustainability currently lacks the component of ownership and how to foster different kinds of ownership over software skills and practices as the primary avenue to software sustainability; and 3) all researchers need to develop advocacy skills and agendas in order to influence any kind of positive change in this area.

References

Heeks, R., 2010. Development 2.0. Communications of the ACM, 53(4), pp.22–24.

Rey-Moreno, C., Bebea-González, I., Prieto-Egido, I., Cochran, S., Foche-Pérez, I., Garcia-Múñoz, J., Martínez-Fernández, A. and Simó-Reigadas, J., 2012. Improving public healthcare systems in developing countries using FOSS: The EHAS Foundation case. In: S.K. Sowe, G. Parayil and A. Sunami, eds., Free and Open Source Software Technology for Sustainable Development. Tokyo, New York, Paris: United Nations University Press, pp.264–287.

Unwin, T., 2009. Development agendas and the place of ICTs. In: T. Unwin, ed., ICT4D: Information and Communication Technology for Development (Cambridge Learning). Cambridge: Cambridge University Press, pp.7–38.

Vallauri, U., 2015. ICTs, Participatory Video and Farmer-Led Agriculture Extension Services in Machakos District, Kenya. Royal Holloway University of London.

Winschiers-Theophilus, H., Winschiers-Goagoses, N., Rodil, K., Blake, E., Zaman, T., Kapuire, G.K. and Kamukuenjandje, R., 2013. Moving away from Erindi-roukambe: transferability of a rural community-based co-design. In: N. Hayes and R. Lèbre La Rovere, eds. IFIP Working Group 9.4. Ocho Rios, pp.363–374.