Lightning talk: A Simple Profiling Framework for Software User- Producer Reciprocity Review Carole Goble School of Computer Science The Software Sustainability Institute The University of Manchester UK Manchester, UK carole.goble@manchester.ac.uk Abstract— Mismatches between users and producers of soft- terms. Responsibility for software support and sustainability ware, or indeed producers and funders of software, lead to mis- should be borne by all parties. ery. We propose a simple software project “reciprocity” frame- Even when software producers explicitly set out to nurture work from the perspective of the producer, covering 4 areas and and grow an open source community (rule 7 in Prlić and 12 characteristics. By plotting the relative degree of some or all characteristics even subjective or rule of thumb values give pro- Procter’s “Ten simple rules for the open development of scien- ject profiles. Such profiles can be useful tools for comparing pro- tific software” [6]), and software users show willingness to jects against their own expectations and desires, to review and contribute, this is still a resource hungry and difficult exercise. compare project types and identify user-producer reciprocity Managing contributions in a “commons production” setting is misalignments. Index Terms—software, profiling, reciprocity. hard, sometimes incurring cost-benefit mismatches, motiva- tional conflicts and significant integration costs [7] as well as I. INTRODUCTION costs in time and effort to oversee the process. Software is fundamental to research: 7 out of 10 researchers surveyed in the UK report their work would be impossible II. A SIMPLE SOFTWARE RECIPROCITY FRAMEWORK without software [1]. Increasingly funding bodies and publish- Mismatches in intentions and actuality between users and ers are pressing for producers to make their software more producers of software, or indeed producers and funders of available for review and for reuse. Furthermore, software pro- software, lead to misery. To gather a coarse grained idea of the ducers are frequently required to show their software’s adop- producer-user profile of a project we propose a simple reci- tion beyond its original development team in order to raise rev- procity framework based on ideas by Crowston [8]. enues to continue development for their own use. Such adop- There are many elaborate software maturity frameworks, tion requires more than just a link to a binary; it requires active some already used by the UK’s Software Sustainability Insti- sharing, documentation, support and commitment to a level of tute: for example, the Software Sustainability Maturity Model service that perhaps had not been fully appreciated by the pro- (SSMM), OSS Watch Openness Rating, NASA Reuse Readi- ducers and may not be welcomed. In a recent study 77% of ness Rating, CMM, and QSOS (see [9] for a useful list). Most respondents cited “time to document and clean up” and 52% include reuse and capability metrics and software and process cited “dealing with questions from users” as barriers to sharing quality reviews. We draw on aspects of the openness rating and code [2]. “Sustainability debt” is a real cost without a clear the “ripeness” levels of the SSMM [9] but from the perspective bearer under our current project-based, novelty-first research of the intentions of users and producers of the software from software funding regimes [3]. Often as software matures, and the viewpoint of the producer. Our simple idea is: highlight community interest rises, the core funding drops. reciprocity and service expectation mismatches; review pro- Software users are also being pressed to more accountably jects’ expectations and desires; and compare against types. credit software [4] and show greater responsibility for support- Table I summarizes the framework, which is intended to be ing the software they depend on. Users can have expectations rough. By plotting the relative degree of some or all character- that software should be freely available and support for it readi- istics, even subjective or rule of thumb values give useful visu- ly accessible. This can run counter to the resources available to al project profiles. For example, Fig 1 is the classic profile for the software producers and to their own interests. Perhaps the software never intended or destined for use outside the walls of software was just a proof of concept or an incidental means to its originating lab. Fig 2 is the profile of a software platform support the work of its originators without any planned subse- developed as part of a computational infrastructure programme quent use by others. In the controversial article [5] users of intended all along for wide-scale adoption. other’s data were characterised as “data parasites”. Software users who do not contribute or cite the software but demand III. WHAT NEXT? support and attention might be considered in such unflattering Our reciprocity framework focuses on the intentions and This work is licensed under a CC-BY-4.0 license. behaviour of producers and consumers of academic software to quickly and simply classify projects; a preliminary and com- plement to the application of maturity models such as SSMM. We need further work to define the levels of each characteristic using analytical and empirical investigation. The UK’s Soft- ware Sustainability Institute (http://www.software.ac.uk) Re- search Software Group, have consulted on 55 software projects, with another 9 currently underway. We intend to retrospective- ly review our consultancy cohort to see if this simple frame- work reveals informative patterns that chime with our experi- ences and to hone our characteristics and their levels. TABLE I. A SIMPLE RECIPROCITY REVIEW FRAMEWORK Software Producer Software User Incidental Built for Me Just my lab me, stuck it Adoptive Community Adoption Intentions out there Familial Built for Family Friends People I people just know Fig. 2. Software intended for widespread use and as an outcome in its own like me right; a service and a possible candidate for further assessment. Fundamental Built for Acquaintances People I others, Strangers don’t know ACKNOWLEDGMENT many not Rivals This work was supported by EPSRC EP/H043160/1. We like me thank the WSSSPE reviewers for their insightful comments. Autocratic I want/need Selfish Download, control use, REFERENCES Contribution intentions no credit Control Intentions Cooperative Community Contribute Champion, [1] S. Hettrick et al (2014) UK Research Software Survey 2014, effort, credit, doi:10.5281/zenodo.14809 credit donate [2] V. Stodden (2010) The scientific method in practice: shared reproducibility in the computational sciences, MIT Sloan Incidental Not my Collaborate Co-resource, core Sponsor co-develop Research Paper No. 4773-10 business, [3] C. Becker, S. Betz, R. Chitchyan, L. Duboc, S.M. Easterbrook, don’t care B. Penzenstadler, N. Seyff and C.V. Venters (2016) about credit Requirements: the key to sustainability IEEE Software 33(1): 56-65. http://doi.ieeecomputersociety.org/10.1109/MS.2015.158 [4] A.M. Smith, D.S. Katz, K.E. Niemeyer, FORCE11 Software Citation Working Group. (2016) Software citation principles. PeerJ Preprints 4:e2169v3 https://doi.org/10.7287/peerj.preprints.2169v3 [5] D.L. Long and J.M. Drazen (2016) Data sharing, N Engl J Med 374:276-277 doi: 10.1056/NEJMe1516564 [6] A. Prlić and J.B. Procter (2012) Ten Simple Rules for the Open Development of Scientific Software. PLoS Comput Biol 8(12): e1002802. doi:10.1371/journal.pcbi.1002802 [7] J. Howison and J.D. Herbsleb (2013) Incentives and Integration In Scientific Software Production in CSCW '13 Proceedings of the 2013 conference on Computer supported cooperative work: 459-470, doi:10.1145/2441776.2441828 [8] K. Crowston, K. Wei, J. Howison, A. Wiggins (2012) Free/Libre open-source software development: What we know and what we do not know, ACM Computing Surveys 44(2), Fig. 1. Software only meant for its producers. Not a service. doi:10.1145/2089125.2089127 [9] R. Gardler (2010) Software Sustainability Maturity Model During the Dagstuhl Perspectives Workshop 16252 http://oss-watch.ac.uk/resources/ssmm (accessed 12 Aug 2016) “Engineering [of] Academic Software” held in June 2016 (http://www.dagstuhl.de/16252), we began to build on the [10] J. Howison (2015) Organizational forms, http://www.slideshare.net/jameshowison/scisoftdays-talk- ideas in this paper, maturity models and on Howison’s howison-spreading-the-work-in-software-ecosystems/18 organizational forms [10]. We are currently developing a set of dimensions to describe a set of software project types to use as a review tool for software producers, users and funders.