SMP stakeholders
We identified two main stakeholders’ groups corresponding to users and adopters. In addition, we defined a group of distinguished personas that are out of the scope of the SMP’s stakeholders, specifically the (a) software users who might also be contributors (e.g. by submitting bugs), and (b) the end-users of the software, who have no involvement with the software development process.
For each group of identified stakeholders we answered two questions:
- (i) how the stakeholders would use the SMP.
- (ii) at which stage of the software development the stakeholders would need the SMP most.
Group 1: Users / Benefiter / Enforcers
This group includes stakeholders that require access to the SMP for a given software, but are not responsible for filling it in.
- Funders e.g ELIXIR, Wellcome Trust
- Policy Makers e.g. European Commission (can use SMPs as a way of “enforcing” their recommendations and policies)
- Service providers (e.g. Compute Platform, PaaS, IaaS, SaaS use an SMP in order to ensure compatibility to the infrastructure offered)
- Software manager not necessarily contributing to the software - making sure principles are enforced
- Publishers e.g. F1000 should use an SMP in order to ensure software “quality” / availability?)
Group 2: Adopters
This group includes stakeholders that are primarily responsible for filling a SMP for a given software.
- Developer/Researcher the person writing the software needs to be aware of the basic principles to follow
- PI of a group can use the SMP to ensure compliance with best practices)
- Organisation (Fundee) Vested interest that in-house research output meets criteria and is sustainable - select appropriate SMP. This is the instance where an Institution is attempting to create a policy for internal use (ensure that any “badged” research software produced under it, aligns to the expectations of the selected SMP)