⇓ More from ICTworks

3 Tensions with Software Sustainability in ICT4D

By Guest Writer on May 3, 2017

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, 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

I have 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.

By Caitlin Bentley, Postgraduate research student, ICT4D Research Centre, Royal Holloway University of London and originally published as Complexities of making software sustainability fit for purpose in ICT4D.

Filed Under: Software
More About: , , , , , ,

Written by
This Guest Post is an ICTworks community knowledge-sharing effort. We actively solicit original content and search for and re-publish quality ICT-related posts we find online. Please suggest a post (even your own) to add to our collective insight.
Stay Current with ICTworksGet Regular Updates via Email

Sorry, the comment form is closed at this time.