Afterlife: the post-research affect and effect of software

Abstract

Software plays an important role in contemporary research. Aside from its use for administering traditional instruments like surveys and in data analysis, the widespread use of mobile and web apps for social, medical and lifestyle engagement has led to software becoming a research intervention in its own right. For example, it is not unusual to find apps being studied for their utility as interventions in health and social life. Since the software may persist in use beyond the life of an investigation, this raises questions as to the extent of ethical duties for researchers involved in its production and/or study towards the participants involved. Key factors identified include the extent of affect created by the software, the effect it has on a participant’s life, the length of investigation, cost of maintenance and participant agency. In this article we discuss the issues raised in such situations, considering them in the context of post-research duties of care and suggesting strategies to balance the burden on researchers with the need for ongoing participant support.

Introduction

Technology, and software in particular, plays an ever-increasing role in research and it is not unusual to find the production and use of custom apps for various reasons. For example, Hasselbring et al. (2020) identify software as an output, as an object of study or as a framework for performing research. To this we can add its use as an intervention in day-to-day life, and in operating the platforms from which research data is extracted (e.g. social media or other collaborative environments).

In this article we are concerned particularly with software applications that are created by researchers (including their wider collaborative teams), that are the (or one of the) subject(s) of research and that play an interventional and/or affective role in the life of their participants. Examples include apps for advice, mindfulness, access to a support community or social group or medical monitoring. Possible investigations within such research might include the way the app is used in general (to identify shortcomings), the benefits or drawbacks perceived by the user, the impact it has on the community as whole and aspects of its technical operation. In considering ethics and compliance, the researchers would typically need to address aspects of data protection, technical support and privacy alongside research issues appropriate to the disciplinary perspective(s) being adopted.

Software in these scenarios is studied as an intervention in the lives of the research participants, raising the question of what should happen to it once the investigation is finished. If the participants have benefited significantly from its use, is it appropriate to simply withdraw their access to it? If not, what duties then fall on the research team by maintaining that access and are these reasonable? Whilst these questions may not have been considered specifically in the software context, they are regularly considered in medicine.

Post-Trial Access (PTA) to medicines has been recognised for some time as an issue in the clinical trial domain (e.g. Sofaer et al., 2014; Sofaer and Strech, 2011; World Medical Association, 2013), and more recently in relation to medical technology (Lawton et al., 2019) and broader post-trial responsibilities (Cho et al., 2018). We posit that many of the issues observed in the medical domain occur also for software interventions. In both domains, if the research intervention has had a positive effect on the participant during the period of research, it has potentially changed the way they live and may have created some form of dependency. Consequently, withdrawal could have a negative effect on the participant’s quality of life. Without careful management of the withdrawal process, care for participants may be neglected. Although the requirement for PTA in medical trials is clearly stated in key ethics declarations (World Medical Association, 2013), it is not stated with practical guidance on how this might be achieved (Sofaer et al., 2014) and there is considerable debate as to the need, reasons and issues involved (see Sofaer and Strech, 2011 for a systematic literature review that draws together a wide range of perspectives on this).

Attention has been paid to the open-science aspects of sharing code and data (e.g. see Darch and Knox, 2017) and the reproducibility and replication of research through high-quality open software as an output from the research process (see, for example, the work of the Software Sustainability Institute (Crouch et al., 2013)). This is valuable but focuses on research quality and future research use, rather than on managing the impact of withdrawing or maintaining interventions on those who have used software in the course of participating in an investigation.

In this article, we aim to broaden the discussion of the ethics of post-research support to the software domain, considering the properties of software and how these require attention if post-research access is to be meaningfully maintained. We argue that the position advocated by Lawton et al. (2019), which is to broaden debates about PTA to include medical devices, should be further extended to include affective software in any domain from the perspective of Care After Research (CAR) (the term introduced by Sofaer et al., 2014 for medical studies).

The article is structured as follows. We first pull together evidence for and against there being an ethical duty to maintain software after research, then discuss the alternative of withdrawing software altogether. The paper then focuses on the agency and expectations of research participants, finishing with a detailed discussion of candidate CAR strategies including open sourcing software, and ending with some conclusions.

A software maintenance duty?

There is considerable debate over both practical and ethical aspects of Post-Trial Access to medicine (e.g. see Sofaer and Strech, 2011) with arguments both for and against. In addition, Lawton et al. (2019) argue that potential emotional and psychological harms need to be included in debates about post-trial care, and information about risks of non-clinical harm should be included in the information given to potential participants. Research software is not medicine, but it can be affective and depending on its context and purpose could have significant life benefits and effects for those who use it. It is therefore important to consider whether it falls under similar ethical duties for continued access.

The broad extent of ethical principles and duties in the context of Information and Communications Technology (ICT) research are described clearly in the Menlo Report (Dittrich and Kenneally, 2012). The Menlo Report framework expands the principles of Respect for Persons, Beneficence and Justice established in the Belmont Report (National Commission for the Protection of Human Subjects of Biomedical and Behavioral Research, 1979) to include Respect for Law and Public Interest, and discusses these from the perspective of ICT research. It highlights the integration of technology in daily life and its mediating role in behaviour and communication and the consequent risk of harm at speed and scale (when discussing beneficence). Stakeholder identification is positioned as a key activity in applying the Menlo Report principles and a wide range of potential stakeholders is discussed, for example there are some who may be impacted by the research (and we argue here, post-research) who are not the direct participants (e.g. a carer for a research participant). The report identifies disruption of access to technology as a potential harm for participants and, at a broader societal level, suggests identifying benefits and harms relating to aspects such as systems availability and emotional well-being. Although the Menlo Report does not specifically address the post-research context, the principles and issues it describes form a useful grounding for the remainder of our discussion here.

Software carries within it significant assumptions about its users. Akrich characterises this as a ‘script’ embodying a designer’s views and assumptions about the users of a technological product, and inscribed into that product (Akrich, 1994). Woolgar (1990) holds a related view, describing the process of design and production as amounting to a ‘configuration’ of the user through defining the user’s identity and constraining their future actions. Thus a piece of software created for a particular piece of research carries aspects of the researchers’ assumptions about the research and the participant/user with it (for example, an app designer may design their user interface to use multi-touch gestures for controlling the software: the designer assumes that the intended user is fully conversant with this mode of interaction and the various gestures that can be used; if they are not, the inscription of that interaction mode into the software constrains its use).

During a research study, the assumptions embedded within the software can be managed and the effect of the technology on its users forms part of the investigation and its associated risk management. However, if the software is made available beyond the end of the study to participants (a potentially ethically positive action as part of reward for participation in research), this active monitoring of risk by the research team is unlikely to be in place. So, whilst software might be seen post-research as merely an output from the research, it is not a ‘declarative’ output in the sense of published results that can be evaluated on the face of their presentation. It is instead an affective output that continues to carry within it (and that enacts) the assumptions inscribed at the time of creation. However, absent planned CAR, it does so without any ongoing oversight to ensure that those assumptions remain aligned to the world as it changes (increasing the risk of what Akrich (1994) identifies as breakdown: ‘the collapse of the relationship between a piece of apparatus and its use’, p. 224). The effect on participants is thus not bounded by the investigation scope if the software continues to be used.

Markham highlights the need to consider the side-effects of research and technology design in the context of impact ethics, including factors outside the control of researchers (Markham, 2018). A software application is the visible tip of an iceberg of code and infrastructure dependency that can change outside of the control of the research team. For example, an operating system update or minor library update can cause an app to fail or look and behave differently, or permissions may be modified leading to new privacy risks (Markham (2018) identifies other risks such as an update making the user feel stupid owing to its complexity).

Mobile apps carry particular additional issues. If these can be installed via an app store, there may be a degree of quality control applied (although this varies depending on the store), but side-loaded apps (those installed by a participant themselves) that require a participant to weaken their device security to allow installation pose a risk, not just from the app itself, but in potentially permitting ongoing compromise of the device security if the weakened security is required for ongoing CAR use.

Where third-party platforms are used to host research applications, there may be post-research risks attached to the terms of a particular platform. For example, organisations may acquire irrevocable intellectual property rights or licences to the applications hosted on their platforms. This would leave researchers without control over the long-term use or withdrawal of their application and with potential reputational risks since they would not be able to prevent ongoing use of the application if it was found to be harmful.

Even where ongoing provision of an application post-research is intended as part of CAR, an unmaintained application may thus be pragmatically ‘withdrawn’ without warning simply by ceasing to function, or may gradually degrade in functionality to the point of uselessness. As a consequence of these potential sources of external change (technical, organisational or human), software needs to be maintained and/or modified to remain relevant to (and possibly safe for) its users. In the context of research software, Darch and Knox (2017) characterise software sharing as a ‘continuous process, even long after the initial sharing of the software occurs’ (p. 296).

Considering these perspectives, if a researcher perceives an ethical duty to make software available post-research as part of CAR planning or reward for participation, they are potentially acquiring a long-term (possibly unbounded) maintenance duty in a complex and changing environment. This duty may relate to straightforward matters of functionality (keeping the software executable in the face of platform or code changes), but may extend also to the information the software contains, or changes in the wider environment. The researcher is also assuming the ethical duties associated with professional software production, for example see the ACM Code of Ethics and Professional Conduct (Association for Computing Machinery, 2018) with a ‘relevant authority’ (BCS: The Chartered Institute for IT, 2015) in the form of the participant(s). They would thus be in potential tension between their role to maintain software to the benefit of their ‘client’, and their role as a researcher to benefit society. Similar issues are found in medical research involving pragmatic clinical trials (Morain and Largent, 2022), although for software the difference may not be so pronounced since codes of ethics for software engineers typically have the public good as the first priority. Another factor arises from the duration of support: Singh et al. (2019) claim that duration is the most contentious issue in PTA since it is not feasible to provide it for an unlimited time. Duration of software maintenance is likely to be similarly difficult to resolve.

Withdrawal as an alternative

Since the burden of maintaining software post-research may be considered too high, we must consider whether managed withdrawal (with appropriate informational transparency in the consent decision) would be a better approach. Or if ongoing access is to be provided without support, how can the former participant be supported to make a truly free decision to continue use in the light of this? In other words, where a participant has been ‘induced’ by virtue of participation to use software as part of a research investigation, to what extent is there a responsibility on the researcher to provide an ‘exit strategy’ to enable participants to exercise agency over their continued use or otherwise? This is analogous to transferring a participant back to existing healthcare regimes following a medical trial as part of PTA responsibilities. Ngwenya et al. (2022) report that one of their participants drew an analogy to the mining industry where there are legal responsibilities for environmental rehabilitation after mining: they described research as a data mining operation and that there should be a responsibility to rehabilitate the community. Whilst the context is very different, the core idea of rehabilitating a participant’s situation (in order for them to make an uncoerced decision about future use) is valuable. The care required in withdrawing systems is recognised explicitly in the ACM Code of Ethics and Professional Conduct (Association for Computing Machinery, Inc., 2018). Clause 3.6 identifies the potential impacts of changes and requires leaders to take care when ceasing support for features that are depended on. It also implicitly requires assessment of risk and potentially assistance for migration to alternatives. Users must also be informed of risks of continuing to use unsupported software.

Creating effective management for withdrawing an app may be thus challenging. Software very often rigidly defines and/or interprets the world in a particular way, driving the user to shape their behaviour to suit it (see Akrich, 1994; Woolgar, 1990). In software development, this highly-directed approach is often termed ‘opinionated software’: the term originates (to the best of our ability to find) with a book chapter originally published in 2006 by the company 37signals (now Basecamp, 2006) and now available online. A contemporary internet search for the term reveals a wide range of informal opinion extolling the virtues and vices of the approach, one viewpoint being that intentional opinionation ensures best practice and another being that it over-constrains. From a research ethics perspective, it is perhaps simply important to recognise that software can be strongly or weakly opinionated and that even in the latter case, there may be implicit assumptions constructed into it about users and how they will behave. Thus, for the researcher, it is important to consider the extent to which their software conditions the thinking of its users and to what extent they can meet any responsibility to nullify this effect at the conclusion of the research (thus leaving the participant a truly free choice to continue using the software or not, or to be unaffected by its withdrawal).

Situations involving software are made still more complex where partnership working is involved, for example with a company providing an app, and an academic researcher studying its use. In these situations, it is possible that a company requires certain permissions to operate the app, but these permissions are not aligned with the research use, or may exceed the scope of the data required for the research. This can have implications for data protection as well as making participant documentation more complex. If such permissions permit continued data collection after the research is complete, care must be taken to ensure former participants are fully aware of this or can opt-out.

To further understand impacts of withdrawal, we can look to experiences of technology withdrawal in the medical trials domain. Lawton et al. (2019) report participant experiences of the withdrawal of a closed-loop diabetes management system following a trial, highlighting that this was a device rather than drug trial but that nonetheless (and despite participants being fully aware of the lack of post-trial access at the outset) there were ethical and other considerations arising from the withdrawal and lack of availability afterward. They report, inter alia, psychological and emotional benefits to the use of the device, improved relationships and greater freedom. Withdrawal was seen as a significant backward step by participants, with some reactions including loss, distress at the increased human intervention once more required, and more negative views of life. Most participants also needed support at the point of trial completion. As noted above, Lawton et al. argue that debates about post-trial care should encompass such harms, and risks of non-clinical harm be included in participant information. Ngwenya et al. (2022) report feelings of loss (of nearby clinics as much as drugs) in former participants in a medical trial, noting that there was a perception of the trial as being a service rather than research, something that is perhaps a greater risk for software investigations since it often plays a service role. Whilst the closed-loop diabetes management study is in the domain of clinical care, it is clear that the device had a significant effect on the lives of those participating and its loss was significant to them. The extent of effect (perhaps also influenced by the length of a trial) is thus an important factor in considering the extent to which CAR may be needed.

Unexpected withdrawal of software (e.g. through technology failure) during a study could provide further indications of the potential impact of withdrawal on participants post-research. Bergin et al. (2023) review the reporting of adverse events in digital mental health interventions but indicate considerable variation and suggest this is to do with the reporting processes and difficulty in recognising such adverse events. Morriss et al. (2021) report technical issues that could have affected the completion of some of their study measures and retention in their study. Kumar et al. (2018) report that technical glitches incurred staff time and likely affected engagement with the platform and affected satisfaction. Gumley et al. (2022) report 13 adverse events related to the app used in their study. These affected 11 people with one event being serious. Most were not technical failures of the app itself although one was a technical fault (described in more detail in Bradstreet et al., 2019) and resulting from unanticipated interaction between the app and a particular mobile device, illustrating the difficulty even within a study of ensuring that software works for participants. Since these examples illustrate adverse events relating to software unavailability occurring during studies, it is not unreasonable to consider that similar issues will occur if software becomes unavailable after a research investigation is complete.

Researchers investigating the effect of software on participants are presumably doing so because they hope or anticipate that there will be some (perhaps significant) benefit to those who use it, otherwise the balance of burden on the participants with the long-term benefit to society may be inappropriate. Commonly-used applications to support activities such as mindfulness, relaxation, prompting and monitoring physical activity and condition, dating and supporting interaction with groups and communities are all likely to have potentially significant effect on the life of the user and their loss may be felt keenly (e.g. see Romano, 2022). We might therefore expect similar withdrawal impacts for software, particularly for longer-term studies.

In summary, withdrawal may seem like a simpler solution than maintenance, especially if participants have been informed of this at the outset, however, as the above shows, it is not necessarily a straightforward exercise when considered from the perspective of CAR. Nullifying the impact of an app may be near-impossible and the side-effects of participation may be impossible to undo.

Expectation and agency

An important factor to consider in conjunction with the ethical duties and impacts on the research team is the expectations of participants. In analysing the sudden withdrawal of Microsoft Office Accounting from the market, Ploug (2010) argues that consumer expectations carry moral weight, linked to the exercise of autonomy that is itself undermined by an inability to make reasonable predictions about the future. Ploug identifies duration of expectation as a relevant factor since the longer an expectation is held, the more significant role it has (duration was similarly identified above as potentially relevant to the extent of effect). The question is therefore to what extent a participant could reasonably expect research intervention software to continue being available, particularly when it is perceived by them as beneficial. From a PTA standpoint, there are differences of view on whether individual benefit to a participant is sufficient to justify ongoing PTA or whether this should only be the case where wider benefit has been found (Sofaer et al., 2014). Ploug (2010) differentiates between limiting the moral issue of Microsoft’s withdrawal to matters of contract only, and ethical analysis based on the moral value of expectation. In the latter, Ploug’s analysis considers factors such as the reliability and size of the supplier, statements made by the supplier about the need for the product and its failure to notify consumers about the withdrawal in a timely fashion (leading to incorrect expectations).

The expectations of participants in a research study are conditioned to a large extent by the information provided at the consent stage. Thus, as long as that information is clear about the extent (if any) of access to the software on completion of the investigation, this could be argued as sufficient to be relied upon in justifying withdrawal if that is the adopted approach. However, participants might reasonably assume that since there is no apparent cost to continuing to provide already-existing software, there is no reason for it to be withdrawn and would thus expect ongoing access. The findings of Lawton et al. (2019) show that even where it is clear and understood that a technology will not be available after the trial, this does not negate the need for care and support in transition back to the previous situation since participants can experience loss in any case. Transparency about this aspect is therefore a necessary but not necessarily sufficient condition to appropriately manage CAR.

Options and recommendations for software CAR

We have identified a range of ethics-related issues in the ongoing provision of interventional software as part of CAR. These include: duties for investigators to maintain software (and the associated costs), the need to manage transition to the post-research stage of software use, the importance of mitigating (where possible) the potential psychological and emotional concerns that arise from withdrawing the software, the provision of transparent information about risks at all stages of the research lifecycle to ensure expectations are appropriate, and the need to respect the agency and autonomy of participants.

Our analysis has led to four main strategies: (1) provide the software without a CAR plan, (2) have a CAR plan that supports transition to alternatives, (3) withdraw the software at the end of the investigation or (4) have a CAR plan that incorporates ongoing maintenance. Each has advantages and disadvantages.

1. Providing software without any ongoing or transitional support (i.e. a CAR plan) runs the risk of ‘breakdown’ between user and technology (after Akrich, 1994) and unexpected impact in the future. The lack of ongoing cost (assuming that the argument for a maintenance duty is rejected) does offer an opportunity for participants to continue using software on their own recognisance. One might argue that this better respects their agency and autonomy than a more protective stance that denies access just in case of harm or owing to lack of resources for maintenance. It may be appropriate to reconsent or otherwise formally discharge the investigator’s ethical responsibility to the participant at the end of the study, in order that the risks of continued use and the lack of maintenance are clearly identified and factored into the use decision. This position may need to be tensioned against the nature of the app and its interventions.

2. Having a transition plan may seem simplest. Post-trial responsibilities in healthcare should include supporting the transition of the trial participants into appropriate follow-up care (Cho et al., 2018), although some investigators were reported to state that it is not their responsibility to organise the public treatment programme to which participants are transferred (Ngwenya et al., 2022). An analogy to this kind of transition in software may be found in the provision of alternative apps to support the same functionality as the intervention, although if such apps genuinely exist, this should raise questions about the novelty of the software intervention and the need for a trial at all. Thus, there may not be an appropriate transitional target.

3. Withdrawing the software on completion of the investigation is simple for the investigators but may induce harms as described above.

4. This leaves the possibility of a CAR plan incorporating ongoing maintenance. Since the costs of this are potentially high for the research team, an alternative needs to be found in which the investigator’s ethical duties can be discharged, the autonomy and expectations of participants facilitated appropriately and the ongoing costs and responsibility shared. The solution to this may lie in open-sourcing the software as part of CAR.

Open-source and open sourcing

Open-source software (OSS) is prevalent in many domains, with millions of developers and billions of contributions (Github, Inc., 2022a, 2022b). Jiménez et al. (2017) recommend open-source approaches as best-practice for research software to support its quality and sustainability, in particular outlining advantages to open development that include increased transparency, facilitation of reproducibility and opportunities for community validation, suggestions and contributions.

Subject to appropriate expertise being available, significant methodological transparency is achieved since the full operation of the code can be inspected and tested. Any assumptions, inferences and deductions made on the output of software used in research can be directly linked and compared to the software method that was used to produce it. From an ethics perspective, there is complete transparency of decision and interpretation providing a stronger ethical defence for the use of the software and its affect and output.

In addition to methodological transparency, open-sourcing means that the software is made available to the former participants in perpetuity if they wish it (thereby respecting their agency) but the investigator is no longer directly responsible for keeping it operational. Darch and Knox (2017) indicate that the original producer of the software must carry the burden of authorising changes, however, this need only be the case until a community has formed and takes collective ownership.

Software can also be changed in response to the various factors that might render it inoperable or no longer relevant meaning that it is at less risk of failing ‘by default’. Where the ‘scripted’ assumptions or user ‘configuration’ (Akrich, 1994; Woolgar, 1990) is no longer appropriate, this too can be changed. As the software exits the research process, it thus becomes malleable to those who wish to continue benefiting from it as former participants (not just to other researchers who wish to reproduce the study).

Moving to community ‘ownership’ also helps to address other ethical issues. Open-source code is typically available under a copyright licence. These vary but typically disclaim liability for the author of the code in terms of any loss or damage caused by it, may contain requirements about attribution, and in some cases, conditions on the reproduction of the code or its use in combination with other code. Licences offer a degree of protection to the researcher, but this may create an ethical tension between the responsibility of a researcher to provide due care for a participant whilst simultaneously disclaiming any responsibility for the effect of their research instrument. Once the research instrument is no longer theirs, this tension dissolves. CAR planning will need to carefully consider the licence under which code will be released, particularly if a partner organisation is providing an app. Researchers may need to negotiate to obtain a version of the app that can be open sourced after the investigation. This may also help to address issues of transparency, parallel data collection and any conflict of interest existing between company priorities and research priorities: these matters would have to be addressed at the outset of an investigation to ensure clarity for all.

By opening the code to the community, the researcher is thus no longer a gatekeeper to the affect and assumptions contained therein and, in addition to the broader research process benefits of open-source publication, open-sourcing offers a potential route to discharge the general ethical duty of software maintenance without losing the benefits for former participants.

Simply making code available is often not enough to ensure usability by others (Darch and Knox, 2017). Essential to the success of open-source software are the communities that form around particular projects. These provide the impetus and resource for ongoing change while retaining community ownership of the projects themselves. Communities will not necessarily develop spontaneously, indeed Howison (2015) argues that organisational change must be intentional to successfully transition from grant-funded research to a ‘peer production’ approach to sustaining scientific software. Wade (2020, para 18) claims that ‘Contributors arise from participants, who all started as users’.

The challenges involved in establishing a viable community of users and contributors around a project should not be underestimated. Pinto et al. (2018) studied several open-sourcing initiatives of previously proprietary software applications and identified a number of aspects that were encountered: the need to welcome newcomers to the development team (described as a non-trivial hidden cost and involving good documentation and interaction), difficulty in retaining newcomers and managing a rise in contributions that must be managed by the core team (at least initially). This burden on the original producer was also noted by Darch and Knox (2017). It is worth noting that many of the systems studied by Pinto et al. (2018) were large-scale and well-known systems prior to their open-sourcing: research applications may be less well-known and require additional work to establish awareness among potential contributors. Howison and Crowston (2014) studied several Free (Libre) and Open Source Software (FLOSS) projects using a variety of methods. They determined three conditions for the success of this kind of open-source development initiative:

• The attributes of the software in terms of ‘layerability’ (the ability to collectively superimpose independent patches or layers), ‘low instantiation costs’ (the ease of rebuilding the existing system to add to it) and ‘low distribution costs’ (the ease with which developers can obtain the system).

• A necessary technical, legal and ethical state in which contributions are ‘irrevocably open’. In other words, contributions once made cannot be withdrawn.

• Time to diffuse an application through the user (and ultimately contributor) community, without which a project may not gather sufficient contributors or identify a sufficient body of ongoing software maintenance tasks and enhancement requests to sustain the processes Howison and Crowston (2014) identify as embedded in FLOSS development activity.

A researcher’s CAR planning may therefore need to include deliberate and active steps to encourage and develop a community around the code that has been released (for practical guidance see, e.g. Behrenshausen et al., 2020), prepare the code appropriately for release and reuse and allow sufficient time to create the conditions for that community to develop and thrive (see Howison and Crowston, 2014). This kind of supported transition is somewhat analogous to the steps taken to transfer participants in health studies back to primary health care systems or to support them as they transition away from the study (see, for example, Lawton et al.’s (2019) description of the informal support from clinicians offered to former participants in the closed-loop technology study). CAR planning may also need to consider alternative and appropriate methods of support in the event that the open-sourcing attempt fails, for example, pointers or referral to other providers of support (e.g. charities, mental health teams) in place of whatever the software was mediating.

In summary, the use of open-source practices offers a way for researchers to discharge their CAR duties without over-burdening themselves in the long-term. Open-sourcing offers agency to former participants and transparency over methods. It is not, however, something that can simply be tacked on to an investigation as an afterthought. To meet the responsibilities of Care After Research, it must be planned from the outset as a programme of activities going beyond the release of the software itself.

Conclusions

In this article we have discussed post-research ethical issues arising from the use of interventional software in research, drawing parallels with drug and medical technology trials. From that perspective we have considered the duties on researchers to provide Care After Research and the implications of these in relation to software. Evidence from a medical technology trial suggests that providing information at the outset is insufficient to deal with all the potential consequences. We have thus argued that there is a duty on researchers to actively manage the post-research phase of an interventional-software investigation from the outset, either by withdrawing the software, maintaining it, finding alternatives or enabling others to take on these duties as they wish to. We posit the use of an actively managed transition to open-source software and community development as one possibility for appropriate CAR provision in these situations.