 Hi, my name is Heather Greer-Klein. I'm the San Vera Community Manager, and this presentation is Unblocking the Future, Finding Done in Open Source. This is a version of a presentation I first gave at the Digital Library Forum in October of 2023. So just a note that if you find this topic interesting, I'll be facilitating a breakfast discussion table at the CNI Spring 2024 membership meeting, and I would love for you to join me. So before I begin, I want to share a little bit about what it means to be a community manager so that you can better understand my perspective. I've been in my role as a San Vera Community Manager for three years now, and in this role, I don't write any code. I don't regularly use any of the repository software that the community develops, and I don't make decisions about the software features or technology priorities. Rather, I coordinate and support the collaboration of many people in institutions who do use these technologies day to day, who build and contribute and maintain the open source code, and who make decisions about the technology and the future of the community. And in this coordinator role, I'm often asked, when will it be done? And you can replace it here with any feature or version or update that the community is looking forward to or needs to have in order to meet their local needs, but that's taking a lot longer to arrive than expected. So I've seen this in the San Vera Community, but also in other open source repository communities and other open source communities in our ecosystem. So I wanted to start a conversation about this problem of seeming to never be done with software updates when we say that we will be. I want to talk about why in my experience we so predictably have these delays and how we might address this issue and get out ahead of the problems that come along with it. So we know that that big changes to critical open source infrastructure like repositories sometimes arrive long after they were promised. Sometimes we even have versions that come out years after they were expected. We also know that no one wants it to be this way. These delays benefit no one. Over promising and under delivering leads to a loss of trust in communities and in their volunteer leaders. Burned out individuals and institutions are left hurt and they might just engage from the project leading to further delays. It also affects open source adoption by creating a perception that adopters need to wait for something. It hurts maintenance and development of other features that are needed in the community as those things get put on hold waiting for the big promised version. So developers and repository managers service providers. Everyone is frustrated when these big releases drag out for months or years. So why so much delay if these delays are toxic to our communities and our technologies. Why do they seem to be happening so consistently. Well first our collective development capacity is shrinking. And by this I mean we have fewer and fewer individuals at our institutions who can do the work of creating and maintaining software code. We compete with industry on pay but also on support on things like designers and product managers. The largest development teams in our ecosystem are a well resourced institutions who may have a mission to work on innovative infrastructure. So they're the critical research and development arm of our ecosystem but they might not be part of every type of maintenance release. And as teams shrink and institutions the demands on developer time are high. If community contribution is a tiny part of duties it could always come last. And if it is purely on a volunteer basis on top of other duties it's not likely to happen at all. And service providers are filling the development gap. And they are the only option for many institutions who use open source but who have no dedicated staff developers. These contractors need to be funded so that they can contribute local work back to community code and participate in the wider community. And community technical leadership is high pressure. And by technical leadership I mean the work of organizing, planning, reviewing, keeping development moving forward and keeping maintenance done in a timely manner. In the same very community we have technical leads and product owners for each component of software that we support. And they're all volunteers with roles at their individual institutions. The wider community gives them a lot of responsibility to meet our collective needs. But they have very low authority. They can only persuade others to contribute work. They have no actual control over who is available, when, for how long, or to do what tasks. That is a high stress position. And also maintaining code is a specific skill set. It's not the same as developing new code. Someone might be brilliant at solving code problems or developing new code, but might not have the skills or the interest in the managing and reviewing and helping others and resolving disputes and so forth that comes along with open source work. In my community and others, we also end up relying heavily on individuals or institutions who are the most passionate, the most invested and willing to do this kind of difficult work. And this is not sustainable because individuals and institutions could start to feel taken advantage of if the work is not equitably distributed across the community. And our most passionate colleagues could feel burnt out and have to step away altogether. And if an institution leaves or an individual leaves, the whole community can face a setback because too much of the work was resting on too few shoulders. I also want to be sure that those of us who uses infrastructure but do not build it. Keep in mind that community built code has unique challenges because it's been built by many people over time. So put simply it's more difficult to work with than something that's being built from scratch. Estimates are also very difficult for the same reason can be hard to estimate how long something will take, how much time, how much funding and so forth. There's a lot of invisible labor, organizing, reviewing, testing and helping others. And a lot of time is lost to context switching moving back and forth between community code and local priorities. And maintenance needs are an ongoing often unpredictable and competing priority to some of these big releases. This is something that's just inherently true for software open source software and proprietary software. Also, 80% of the time is spent on the last 20% of the work is a maximum that I've heard about software development. And based on my experience and experience of other open source communities, a lot of times we do end up having the longest delays and getting the most bogged down in that last 20% of work towards a big version or a big release. And then there's factors that are inherent to customization. If things are very custom locally can take a lot more time to upgrade. It requires more planning requires waiting until the big release out to see what's different to see what's required. So this can make it feel like even longer for some of these big releases to be implemented. And volunteers are people. So all of the institutional and personal and global stresses that everyone is suffering under greatly reduce our capacity for volunteer work and our capacity for contributing back to community. So what can we do. The most important place to start to prevent these issues is at the community level. So if you rely on open source software to critical component of the work that your institution does, then you and your institution are part of a community. And you can help to make sure that the software that's so important to you has a strong foundation and we can prevent some of these problems later on. So first is making decisions early and often a clear governance structure makes for a much easier decision making, having community leaders, having a board of this. This goes a long way. Also processes for community input having a way to gather use cases to make sure that all different types of institutions and individuals are heard from before planning for a big change or a big feature. It's really, really important, but also knowing when to end that input process and actually begin the work also having processes in place for decisions that come up along the way. That's a place where communities can really get bogged down if developers are working and they don't know who to go to or how to resolve a problem that could affect the whole community. Things can really grind to a halt and also building with flexible and common and standardized underlying technologies. So planning for the future and thinking about ways to make our code more durable and easier to work with so that the next big version change or update is less difficult or impactful and more developers are available to work on it. It's not super specialized. We also need to match our expectations to the level of activity that's happening. So celebrating smaller milestones, knowing that this is really where done lives where things happen. We can make lots of progress towards a big release, but a lot of that progress can be not noticed by the wider community, not appreciated if the focus is really on a big version. So thinking about ways to break down that work, chunk it out differently, talk about it differently will help us be able to appreciate the work that's being done. And be less caught up on big versions or big changes, big releases. Also regular communication, particularly of when work is happening, who's doing the work and when work isn't happening when more volunteers are needed. If you're not sure who's doing what work or if it's happening, it may not be happening at all. Also concise and frequent calls for help to reach specific goals, whether that's through funding the work, having service providers contribute or asking for developer hours from community members. Anything that we can do to keep momentum going and taking care of people having leadership terms so people don't feel like they're stuck in a position forever. So that they know there are other people who can help who can take that on recognizing all of the invisible labor that happens in open source, recognizing and celebrating all of the people who write documentation and so forth. Finding sustainable staffing models that might be centralized staff who are hired by the project that might be moving important community volunteer roles around between institutions. And then continuous improvement to the contribution process, always doing retrospectives, thinking about ways to make sure that feedback is taken and things get easier over time. So software adopters, long term solutions to these kind of problems are really going to require increased sustained financial investment. We need to make up for the reduction in available volunteer time. And we need to be planning to contribute financially or through staff time consistently every year. Also consider how community processes could change to make your contribution easier. Is there a way that your open source software community could ask for volunteer hours or ask for finances at different times of year. There's anything that can be done to make it easier for you. Make sure that your community leadership knows because they'll be happy to be creative to help that happen. And also stay engaged. Make sure that someone is paying attention to the community. If there's development happening that's important to you, keep up with the process, see where you can help make sure there's not reduced efforts. And notice if there are things that get in the way of your engagement. Again, so that you go to community leadership and talk to them about ways to help you or your staff stay more engaged. So again, just a reminder, if you find this topic interesting, I'll be facilitating a breakfast discussion table at the CNI spring 2024 membership meeting. I really love for you to join me. And together we can get from when will it be done to whatever we're going to do next. Thank you.