Fundamentals of software sustainability
Download as PPTX, PDF2 likes514 views
The document discusses the concept of software sustainability, highlighting its importance for various stakeholders including users, funders, managers, and developers. It addresses the risks of software collapse and stresses the need for resources, support, and community involvement to maintain software functionality over time. Key metrics for sustainability include the inflow of resources and human effort, with an emphasis on the unpredictability of software longevity.
Fundamentals of software sustainability
- 1. Fundamentals of Software Sustainability Daniel S. Katz (http://danielskatz.org, @danielskatz)
- 5. What is sustainability? • Most often used in the context of ecology, often specifically in the relationship between humans and the planet • Example: Karl-Henrik Robèrt (via Wikipedia & paraphrased) • Natural processes are cyclical but we process resources linearly • We use up resources, resulting in waste • Waste doesn’t find its way back into natural cycles; not reused or reassimilated • Call for "life-styles and forms of societal organization based on cyclic processes compatible with the Earth's natural cycles"
- 7. Software sustainability for whom? • Users • Funders • Managers • Developers (Maintainers)
- 8. Software sustainability for users • The capacity of the software to endure • Will the software will continue to be available in the future, on new platforms, meeting new needs? • Really: • Shopping • With elements of • Longevity • Robustness • Support
- 9. Software sustainability for funders • My definition while an NSF program officer: • “If I give you funds for this now, how will you keep this going after these funds run out?” • “… without coming back to me for more funds” • Really • Portfolio management
- 10. Software sustainability for managers • Focused on people, not software • How do I keep my team going? • Really: • Business • Capitalism • Entrepreneurship
- 11. Software sustainability for developers • Often focused on resources, not software • How do I get the resources needed to keep my software alive and up-to- date? • And keep myself supported / employed? • Counterpart • How do I make keeping my software alive and up-to-date use less resources? • Really • Entrepreneurship • Community building • Software engineering
- 12. Software collapse1 • Software stops working eventually if is not actively maintained • Structure of computational science software stacks: 1. Project-specific software (developed by researchers): software to do a computation using building blocks from the lower levels: scripts, workflows, computational notebooks, small special-purpose libraries & utilities 2. Discipline-specific software (developed by developers & researchers): tools & libraries that implement disciplinary models & methods 3. Scientific infrastructure (developed by developers): libraries & utilities used for research in many disciplines 4. Non-scientific infrastructure (developed by developers): operating systems, compilers, and support code for I/O, user interfaces, etc. • Software builds & depends on software in all layers below it; any change below may cause collapse 1http://blog.khinsen.net/posts/2017/01/13/sustainable-software-and-reproducible-research-dealing-with-software-collapse/
- 13. Software collapse1 • Options similar for house owners facing the risk of earthquakes: 1. Accept that your house or software is short-lived; in case of collapse, start from scratch 2. Whenever shaking foundations cause damage, do repair work before more serious collapse happens 3. Make your house or software robust against perturbations from below 4. Choose stable foundations • Very short term projects might do 1 (code and throw away) • Most active projects choose 2 (sustainability work) • We don’t know how to do 3 (CS research needed, maybe new thinking) • 4 is expensive & limits innovation in top layers (banks, military, NASA) 1http://blog.khinsen.net/posts/2017/01/13/sustainable-software-and-reproducible-research-dealing-with-software-collapse/
- 14. Common elements • Due to software collapse, bugs, new use cases, there are lots of risks to all parties • Users want to make good product choices that pay off in discoveries • Funders want to make good investments that pay off in discoveries • Managers want to keep staff employed, also create discoveries • Developers want their software to be used in discoveries (and want a career) • (Almost) all want to know, will this software work in the future? • What’s the risk? • And how do developers get recognized?
- 15. Back to sustainability, in the context of software • Elinor Ostrom’s (Governing the Commons) definition of sustainability for a common-pool resource (CPR): “As long as the average rate of withdrawal does not exceed the average rate of replenishment, a renewable resource is sustained over time.” • Notion of a cyclic property, though cycle period not specified • But rate of what? • Titus Brown1: “the common pool resource in open online projects is effort” • Sustainability of effort may be appropriate for the developer • For effort to be available, need link to recognition, reward, position • Sustainability of software may be appropriate for the user and funder • Rate of what? • Sustainability of funding may be appropriate for the manager • Also helps developers • Rate of funding? 1A framework for thinking about Open Source Sustainability? http://ivory.idyll.org/blog/2018-oss-framework-cpr.html
- 16. “Equations” of software sustainability • Software sustainability ≡ sufficient ∆ software state • Sufficient to deal with: software collapse, bugs, new features needed • ∆ software state = (human effort in – human effort out - friction) * efficiency • Software stops being sustained when human effort out > human effort in over some time • Human effort ⇆ $ • All human effort works (community open source) • All $ (salary) works (commercial software, grant funded projects) • Combined is hard, equation is not completely true, humans are not purely rational • ∆ software state → users choose to volunteer effort or $ • Development choices might take this into account Debt: The First 5,000 Years by David Graeber ?
- 17. Software sustainability and time • Software sustainability is a measure of a dynamic, (unpredictable), time domain system • Back to risk… • Software sustainability is a prediction – it can’t be known with certainty • Software sustainability can only be measured looking backward • How do we know that software is no longer sustainable / has stopped being sustained? • It no longer works at all? (continuous integration fails) • It’s not being actively maintained? (no commit in the last x months) • It’s not being actively developed? (no non-bug fix commit in the last x months) • What do we do for similar measures in other fields? • Guess (aka estimate) • Based on past performance • E.g., Project cost • Research is needed
- 18. Summary • Software sustainability means different things to different groups of people • Persistence of working software • Persistence of people (or funding) • Can define sustainability as • Inflow of resources is sufficient to do the needed work • Those resources can be turned into human effort • In all cases, sustainability is not possible to measure in advance • Can only measure looking backward • Looking forward, can only predict
- 19. Acknowledgements • Discussions with Neil Chue Hong and the UK SSI • Discussions at various WSSSPE workshops • Keynote by James Howison at RSE2018 • Discussions with Rob Haines and Caroline Jay at U. Manchester • Feedback from Matt Turk, James Howison, Dan Sholler • D. S. Katz, “Scientific Software Challenges and Community Responses,” 2015. https://www.slideshare.net/danielskatz/scientific- software-challenges-and-community-responses • C. C. Venters, C. Jay, L. Lau, M. K. Griffiths, V. Holmes, R. R. Ward, J. Austin, C. E. Dibsdale, J. Xu, “Software Sustainability: The Modern Tower of Babel,” Proceedings of Third International Workshop on Requirements Engineering for Sustainable Systems (RE4SuSy 2014), Karlskrona, Sweden. http://ceur-ws.org/Vol-1216/paper2.pdf • C. Becker, R. Chitchyan, L. Duboc, S. Easterbrook, B. Penzenstadler, N. Seyff, C. C. Venters, “Sustainability design and software: The Karlskrona manifesto,” 37th International Conference on Software Engineering (ICSE’15), 2015. https://doi.org/10.1109/ICSE.2015.179 • P. Johnston, M. Everard, D. Santillo, and K.-H. Robèrt, “Reclaiming the Definition of Sustainability,” Environmental Science and Pollution Research, v.14(1), pp. 60-66, 2007. https://doi.org/10.1065/espr2007.01.375