 Right, so I'm going to talk about what I think is important about software sustainability and when I was getting ready to come here and give this talk, I realized that a lot of what I think about is software sustainability really means research software, research software sustainability and not software sustainability in general. So I'm gonna kind of, in some cases I'll probably say software sustainability still but I really mostly mean research software but not entirely and I'd be interested actually as we go through if people have thoughts that are, people are coming from open source communities that really have nothing to do with research, how much they think this makes sense and how much they think it doesn't or what parts really are the same or different. So okay, so keep that in mind as you're listening, thank you. So the first thing I think that I would say is I'm coming from an academic field, I'm at University of Illinois and so I tend to think sometimes about asking questions and then thinking like what, how would a student answer these questions and so I think if we think about what is sustainability the way a student would answer that is that they would Google it and if you look at this, Googling sustainability, the one thing that I think I can see from this is that sustainability is very green and I'm not sure that there's really much else that you pick up from this, it's also kind of round, it's got a tree in the middle. Anyhow, so the other thing then is cartoons are also good and so this is the use of the word sustainability over time which says that by 2109 every sentence and every word will include sustainable and maybe every word in every sentence will be sustainable, so that's probably bad. Okay, so more seriously, sustainability in this general sense is often used in the context of ecology which probably everybody knows and it's usually in the relationship between humans and the planet and Carl Henrikrober says that natural processes are cyclic, but we humans process resources linearly, we use up resources resulting in waste and that waste doesn't find itself its way back into natural cycles, it's not reused or re-assimilated and so Robert called for life cycles in forms of societal organization based on cyclic processes compatible with the Earth's natural cycles and so that's kind of this definition of sustainability that I think is pretty reasonable although I will say in general media if you hear somebody talk about sustainability they could be talking about almost anything and it very rarely actually means sustainability in the psychological sense. Okay, so then software sustainability instead of general sustainability. I think the first question that we really have to ask is who are we talking about because different people have very different views of what this means. In particular I believe there's a view that users have, there's a view that funders have, there's a view that managers have and there's a view that the developers or the maintainers have and I'm going to kind of use developers and maintainers very similarly here even though I recognize that these are not always the same. So going through these one by one for users software sustainability is really often the capacity of the software to endure. So they ask questions like will the software continue to be available in the future on new platforms meeting new needs and this really in some senses is just shopping. This is not a question about sustainability this is a question about which software should I use. It also though has elements of longevity and robustness and support and these are kind of the subsets of things that people may be thinking about when they're trying to figure out which software to use. From the point of view of funders, so I was an NSF program officer for four years until about three years ago and the definition that I gave was if I give you funds for this project now how are you going to keep it going after those funds run out. And then people would answer and in order to make them not answer the question that way they wanted to I would then say without coming back to me for more funds because that almost always is the first thing people would say. And so this really I would say is portfolio management. All right this is a funder that wants to build things that they can be proud of they want to build a set of things. And they want those things to endure with as little money that they put in as possible they want to get the biggest kind of bang for their buck. For managers, let's say somebody that's managing a software project, they're usually actually focused on the people rather than the software I think. And the question that they ask is how do I keep my team going? And so this really in some sense is just business this is not really related to software very much at all. It's capitalism, it's entrepreneurship and I think that's it. Yes, okay. Sorry for some reason I don't have a preview which is very strange. Software sustainability for developers which is probably the way that a lot of people think about this is often focused I think on resources more than software. And it's this question about how do I get the resources that I need to keep my software alive and up to date? And how do I keep myself supported and employed? And these two questions often come together I think. The counterpart of this maybe is how do I make keeping my software alive and up to date use less resources? And so how do I make this easier for myself? And so this is really again, it's really kind of entrepreneurship. And it's also community building if you think about it in terms of using less resources of your own, can you bring in resources from somewhere else to help you? And it's also software engineering, right? So what are the best practices that should be used? What are the community practices that could be used? What are the good enough practices that that actually do get used? So I want to actually introduce them software collapse here. I don't know if anybody has seen this or not software collapse is an idea that Conrad Henson wrote about two years ago or two and a half years ago on a blog. And this paper in Computing and Science Engineering that's footnoted here and these slides are in Zanotto so you can get to it from there. This paper came out I think either last I think it came out on Friday last week. And it's great because it actually says a lot of the same stuff that's in the blog but it but it says it in a much more easily citable way. So Conrad says that software collapse is the fact that software stops working eventually even if it's not actively maintained. And in particular we have computational science software stacks and this could be data analytics software stacks as well it's not particularly different. That have on the bottom a layer of non scientific infrastructure which is developed by software developers including operating systems and compilers and support code for IO and user interfaces and things at that level. And then on top of that is a scientific infrastructure developed by developers again libraries and utilities used for research in many disciplines. So I guess just thinking about this in terms of data science. This could be Linux this could be a bunch of the sci-fi stuff things like that. And then on top of that are discipline specific software sometimes developed by professional developers but also developed by researchers. And these are tools and libraries that implement disciplinary models and methods. And so an example of this in data science might be Astro Pi as or something like that. And then on top of that at the highest level is the project specific software which is almost always developed by researchers almost never developed by actual software developers. And it's the software that actually does something using all the building blocks from below and it's the scripts and the workflows and the notebooks and little special purpose libraries and utilities that make all of these things work to solve the particular problem that somebody wants to solve. And the thing that's important is that any piece of software is building on and depending on the software and all the layers below it and any change below can cause collapse can cause the software to stop working. So the thing that Conrad did that I really like is that he compares this then to house owners that face the risk of earthquakes. And so for people in Portland I don't know. Some people are thinking about this actually my sister got an earthquake gas shut off valve on her gas like a year ago which I was very surprised to see when I was there. But in California which is where I was for a while this is much more common. And the options are that you could accept that your house or your software is short lived and if it collapses you start from scratch and rebuild it. And so maybe this is what you do with the shed behind your garage or something like that. For your house itself you may accept that the foundations are going to shake occasionally and they're going to cause some damage and when that happens you're going to do repair work bring everything back to where it was and kind of keep doing this so that you don't have any serious problems. You could also make your house or your software robust against perturbations from below. So this is what gets done for like hospitals and schools and other things they put in some kind of ground isolation to say that we know that the bottom is changing but we're going to put in a layer that's going to make us not feel that change at the top. And then the last thing that you can do is to choose stable foundations. And I don't actually know if this is something that's really possible to do in the real world in terms of houses or buildings. In theory you could think about going to bedrock but that doesn't quite work because the bedrock is also shaking. Maybe it shakes less than the alluvial plane anyhow. So we have these different situations. So short term projects might do this first one. You rewrite your code and you throw it away. This might be what the individual scientist does if they're not thinking that they're going to keep their code for a while. They're just doing this to write kind of one paper to get one result. Most active projects choose the second one and we could just call this sustainability work and this is part of the work that needs to happen to make software keep working. Is that you have to keep an eye on what's going on below and you know that your code is going to stop working sometimes. Or that it might if you don't change your Python to use Python 3 instead of Python 2 or something else. We don't really know how to do the third one. I don't think at least in software and it's possible that there could be some computer science research or some new thinking that thinks about how do we insulate away from APIs that could be changing. Can we auto generate APIs in some way. So there's different things that could be done there but I don't think we have a good answer. And then the fourth one you can do in software but it's really expensive and it limits the innovation that you can do in the top layers. But this is what happens in some cases like some banks although I'm starting to think that this may be completely untrue for banks but for the military and for NASA and other things at least. So thinking about all of these together we have this fact that software collapse bugs and new use cases are going to cause a lot of risk to all parties whether you're a user, a funder, a manager or a developer. And users in particular as I said before really want to make good product choices that pay off in terms of new discoveries. Again I'm thinking research and science here. This may be slightly different if you're in a different area. Funders want to make good investments that again pay off in discoveries because that's really what the funders are interested in in the end. Managers want to keep their staff employed and if they can do something useful along the way that's great as well. I'm sorry I'm being a little negative towards managers which I am so apologize. And developers want to keep their software going. They want it to be used in discoveries and they want a career. And almost all these groups in some sense really want to know will the software work in the future? That's really the kind of the underlying question. And what's the risk? Alright so not will it but how likely is it? And I will say that the last thing that I think is also important here is how do the developers get recognized? And I think that this actually impacts almost all of these other groups as well. That they all need to think about this to some extent. Some do and some don't as much. Okay so back to sustainability in the context of software. So Eleanor Ostrom a Nobel prize winning economist in governing the commons defined sustainability for a common pool resource which we don't need to talk about too much but we can if anybody wants to. As the statement as long as the average rate of withdrawal doesn't exceed the average rate of replenishment a renewable resources sustained over time. And this kind of makes sense if you're thinking about a reservoir, you're thinking about a pasture or something else that you're using up some part of it you need to let it replenish or replenish it in order to continue using it and to have it be sustained over time. So this has some notion of a cyclic property. It doesn't really define what the period is of that cycle. And it also doesn't actually say what's being sustained necessarily that's something both of these questions depend on exactly what you're looking at. So if we think about software we have a blog post from Titus Brown who suggested that the common pool resource in open online projects is effort and that this is the thing that we should be thinking about is the effort sustained and sustainability of effort I think might be appropriate for the developer. And if this is the case for this effort to be made available for it to be continued to be brought in to the system, there needs to be a link to recognition and reward and position for the people that are actually putting in this effort. They have to have some reason that they that they do this. Sustainability of the software itself may be the thing that's appropriate for the user and the funder. They may not actually care about the effort that goes in but they want to know kind of is the software being sustained in some way. It's not exactly clear how that matches a common pool resource because I don't know what the rate of software in or software out is because when you use software you don't use it up and I don't know what bringing it in means. Yeah, sorry, I'll stay away from the economics part. And then sustainability of funding might be the thing that's appropriate for the manager. Am I getting in enough funds to pay the people who are spending money and continuing to use it? And this then also does help developers. And so maybe this is again rate of funding. Okay, so I'm going to now go off on a slightly strange direction and say that because we're talking about research I'm going to come up with some quick equations for what software sustainability means. And so the first one is that I'm going to say that software sustainability can be defined as a sufficient change in the software state over time. That's I'm just going to say that that's the case for this point. And sufficient means sufficient to deal with software collapse and bugs and new features that are needed. I'm also going to say that the change in software state is equal to the human effort in minus the human effort out minus friction times efficiency. So this is kind of going with what Titus was saying about effort being the thing that cyclic, which I kind of believe, right? There's also some friction that makes it actually hard for people to do work. And if you can reduce that, that's better. And then there's also some efficiency, which kind of is related to friction, but it's not exactly the same, but we'll treat it the same for the minute. And so then the idea is that software then stops being sustained when the human effort out is greater than the human effort in over some time. Right? That's when the project dies because it's no longer being sustained. The another thing is that human effort is kind of equivalent to money. It's not really, but it's kind of, and I'd say that this book debt the first 5,000 years is great if anybody's interested in thinking about money and where this concept comes from that actually has no basis in reality. And so we could say that all human effort works well. Right? If we have human effort, that's a great way of running a project. That's how community projects work a lot of the time. We could also say that all money or salary works really well, and that's how commercial projects work or grant funded projects. And the question is if we combine these, does this still work? And this is, I think, a big question that a lot of people ask. If because this equation isn't really true, you can't really trade off human effort for money. Exactly. You can kind of buy effort, but it doesn't necessarily go the other way. And humans aren't purely rational, and so we make choices that aren't entirely based on money as well. And then the last thing that I'll throw in is that it's possible that you can think of a change in software estate, maybe, as implying whether users are going to choose to volunteer effort or money later. And if you think about that, you could actually say then that development choices might take this into account. So you might make choices about your development not based on who your users are going to be, not based on what features people are asking for, but based on is this going to make the project more sustainable because people are going to be more willing to contribute to it, either to pay for it, to donate to it, or to actually volunteer and do work on it. And so I think this is actually an idea that maybe projects don't do very often, but maybe they should be doing more. Okay. So let me wrap up. I'm sorry, I'm running slightly late. So software sustainability means different things to different groups of people, persistence of working software, persistence of people or funding. We can define sustainability as the inflow of resources is sufficient to do the needed work. And these resources can be turned into human efforts to some extent. And then the challenges are, how do we bring in more resources, either funding or people, which I think leads to questions about incentives? And how do we reduce reduce the needed work, which leads to questions about best practices? So there's some potential solutions, I believe. So one is, can we convince governments and funders of the importance of software and the sustained funding for some of it? I think a lot of people would like to do that in research software. There's a group called the Research Software Alliance that a few of us have started up that is trying to do this in a unified way across a bunch of different governments. And there are certainly lots of others that are also trying to do this. Another thing is to use software citations to aid developers to give them credit for what they're doing in a way that matches what they want, at least in academia. And so in the 411 software citation implementation group, we're working on how we do this. And so I think we're making progress there. We could also try to build better career paths for developers overall. And research software engineering movement, the RSE movement, which is mostly in the UK, but we're actually now starting a bit in the US as well, is a way to try to do that. Again, this is like kind of a very quick version of lots of things that could each be half hour talks. So if somebody's interested, I'll be here the rest of the day and tomorrow as well and happy to talk about any of these things. And then the last thing I think is to develop and use software best practices. Sorry, there might be one more coming. So we had the carpentries talk earlier today. One activity that we're kind of talking about with the carpentries would be project carpentry. And the idea of that would be, can we build something that helps new projects figure out what they should be doing when they start as new projects? What are their best practices? And there also are incubators like ESIP and Apache that do things to help with this. And then the last thing is that there are a bunch of different groups that are working on this. So the software sustainability institute in the UK, the US Research Software Sustainability Institute or IRSI that I'm working on in the US, NumFocus and Code for Science and Society are some of these groups that are that are involved in all these questions. So this is kind of the group landscape, the landscape, the big kind of space of where things are going on. If you're interested in doing something personally, then there's a bunch of things that you can do as well. And so I'll just close by saying what some of those are. So one is that you can think consciously about software sustainability in your projects. And try to make decisions that are best for the project in the long term rather than best for the existing users in the short term. And that those ideally are going to be the decisions that lead to decreased work and increased resources. You can give back to open source. So if you use open source, I think you have a moral obligation to give back in some way. My guess is that probably a lot of people here would agree with us. But if we go outside and talk to people more widely, I'm not sure. But you also should be encouraging others to do so. And you should do this either personally or institutionally in terms of where you work to try to see how this happens. Or trying to make the system work better in some other way. You can support software developers and maintainers. So if you're involved in hiring or promoting somebody, you should certainly be including their software work in that decision, even if it's not a software position, but they do something that's related to software. And you should try to make sure that your institution provides appropriate career paths. And this is again, particularly for people in universities. You can support software citation. If you're an author, you should cite the software that you use. If you develop software, you should make it easy to cite so that other people can cite your software. And if you review things, make sure that software cited is part of your review process. So with that, a bunch of different people and things that I've been thinking about and talking about talking with over the period of probably six months or so. So thank you.