 Good afternoon everyone. By my computer's clock we have just arrived at 45 minutes past the hour. I'm delighted to be here but I can confirm as Cliff said earlier it is absolutely dazzling up here so it's very hard to see anyone and that might be interesting when we get to the hopefully questions part of the panel. I hope Cliff and Diane will forgive us but we're subject to an off by one error in the naming of this panel. I'm delighted that Elizabeth can join us from Chicago. We will all introduce ourselves when we make some introductory statements but I'll just give maybe just a couple of moments of background. This panel comes out of a series of really useful discussions a number of us have been having as IT directors at research libraries that are implementing or thinking about implementing folio. We find these are useful because we have a bunch of issues that might not be shared by all of the folio community, things that bring to mind for me are issues of scale, the amount of usage we put folio to and the sort of types of integrations we're thinking about. Next slide please Sean. So just in case this isn't something you're already fully familiar with what is folio? I like always to start off by saying folio is a really cute acronym the future of libraries is open but we certainly hope it is. But more than that folio is an extensible library services platform and I think here we're making a distinction between a library services platform and an ILS in the sense that it is designed to be the foundation for additional functionality beyond what might be included in an ILS. So things that come to mind in the way I'm thinking about things are what about some of the reporting functionalities associated with folio? How might we leverage that to do reporting around things that are not traditionally part of the ILS? Or what about the module we add into support control digital lending in a very smooth way? That might be nice. The folio community is an open source community and most interestingly it's a collaboration between librarians developers and vendors the unusual part there being between academic institutions and vendors. That I think gives it great strength. In the last year we've spent additional effort that's part of the community reformulating and formalizing the governance model to add a third council over the pre-existing technical council and product council the community council to sort of look after the overall health and structure of the community including governance going forward. And I think the third bullet there folio is an opportunity for us as libraries to actively shape infrastructure that is key to our operations in a way that will evolve to meet our needs. I think just to make a distinction here although a number of us on the panel are involved in folio community and project governance as far as this panel we're speaking as ourselves as part of our institutions. And Sean, next slide please. I think first up is Elizabeth. Hello I'm Elizabeth Long I'm the associate university librarian for IT and digital scholarship at University of Chicago and also currently the interim library director. And we all are going to talk a little about our own kind of situations in regard to folio and maybe our journeys to get to where we are now. And so I wanted to start with in 2014 when we launched Olay and view find. And so we had been part of already a community building software to support out traditional ILS or LMS functions at that point we launched both of those as locally hosted pieces of software. And after a not too long period of time we then got to the point where Olay was clearly transitioning into something different and ending itself. And so in 2017 we put together a task force to evaluate what our options were. We knew that Olay was going to be end of life and so we needed to think about what our next move was going to be. And what came out of that we did not want to make an assumption that because the Olay community was kind of retooling and becoming folio starting in many ways from scratch but it was the same group of people who were involved to some extent. But we didn't want to assume we were just going to folio so we really did a pretty thorough evaluation of the options. And we came away from that very excited by the vision that folio had and I think part of what Simeon was just talking about thinking of it not just as a traditional ILS or LMS but really thinking of it as a platform that was extensible and could be thought of going in many different and new directions. And that was very exciting to our staff. It also we realized was a very good cultural fit for us. We were used to having direct access to our database, to our data. We were used to having involvement in the development of the software. We were very committed to open source. And so all of those made us make that decision that we wanted to go with folio. And at that point more fully commit ourselves to involvement in all of the governance structure, the different special interest groups that were defining what folio was becoming. And we have a lot of staff who've been very deeply involved in that since 2017. So our original goal was that we would be going live in July of 2021. We had the traditional belief that we'd always held that you could only do a system change at fiscal year rollover. And as it became clear that folio was not quite ready for us, but also we were not quite ready for folio, we put that off. And what we were aiming for was actually what would have been a launch today that is not happening. I'll talk a little about where we went instead. So we had been aiming for, we turned around and said, we actually realize we can go sometime other than fiscal year rollover. That's a doable thing. And that was a really important step forward for us in how we thought about implementing a system. During all of this time, we had a real lack of staffing. We had some open positions that especially once the pandemic hit, we had hiring freezes and we're not able to fill those. But we also had so many other competing open positions that we had a real problem thinking about how do we manage this project going forward. And so we actually contracted with index data to act as project managers for us just doing the prep to get to where we could be thinking about what planning migration itself would look like. We have also subsequently worked with them and they are going to be our hosting provider and are working with us very closely on our migration. In the meantime, something else I wanted to call out was a collaboration that ended up happening between us, Cornell, Duke and TAMU, where we realized there were some things we wanted and the highest priority one was an integration with OCLC's connection. And so we worked with index data to build that as something that we did to bring back to the community but kind of separate from the ongoing folio schedule for when things would get done because we saw that as high priority. And that's the type of thing that really was for us. The vision we were looking for was an ability to have partners and to work on things that were high priority to us. So we did go ahead and launch our ERM module in July because that was not something we had. And so it was a new thing and that was easy to go ahead and launch. But we did do that delay. And just at the end of November, we realized that we were not fully ready for folio. We had a couple integrations that were still complicated. And so our new go live date is the weekend of Martin Luther King. We'll be launching on MLK Day and doing that full migration over that weekend. We're going to be going live on Juniper. I think we're all talking about which version we'll go live on. And so we're still also going to be using View Find. We've redone it under the hood to point at the new version, but that we're not changing. We're hoping that it will be very seamless from our patron perspective. So I think I'm turning it over now. Yes, to Cornell. I think it's me again. Yes. So I guess I'll start our story from what Elizabeth just mentioned. In 2014, we separated our discovery system from our Voyage RLS adopting Blacklight. And that has worked out very well for us. We really have had remarkably few patron facing changes as a result of our move to folio. And we've had to change some of the integrations associated with that, but not the system itself. So that allowed us to, you know, split a big problem into two slightly smaller problems, which is always a good idea. We did a significant analysis of the environment in 2015 with Columbia as part of the two COOL project then where we looked at Alma and folio. And shortly after that, Cornell decided that it would move ahead and join what was then the Olay Consortium, although it had already, as Elizabeth mentioned, pivoted toward a new vision of what would become folio. So that was our first engagement with the project. And we've had Holly Misslebauer, for example, who's been involved in that work for the community ever since that time. We had originally targeted a July 2020 go live. But as we tracked the progress of the project in 2019, it became clear that the project would not be ready to meet our needs in the summer of 2020. And indeed, I think that was a sensible assessment. And we delayed our go live to July 2021. We did move forward. We were, at that time, self-hosting a development version of folio. And in early 2020, we took just a smaller part of the system around our ERM, the current resource management functionality, and went live in January. What, as IT director, I later found out was our development system. But that's fine. So that went successfully in January 2020. And later that year, we contracted with EBSCO, both to help with our migration and for hosting going forward. So we actually did, later in 2020, a migration of this ERM functionality from our self-hosted version into the EBSCO hosted version, which went very smoothly. And from that time, it was heads down, track all the things that we had decided were really essential and worked toward a go live of summer 2021. We had not overcome the hurdle Elizabeth mentions of considering a go live other than our fiscal year boundary, which is July 1. And we never got past that. So while we were coming up toward our July this year go live, it was really for us a decision, are we going to go this year? Is Folio ready? Or do we have to wait another year till July 2022? We determined in the end that it was ready, and we did go live, and we are live, and it is working. We don't have everything we want, and I think we'll probably be talking about this a bit more. But our libraries are, you know, checking out books and all the things they do. Just at the end of this week, we're upgrading from Iris, which is the version we went live on to Juniper. And that's our next step. Hi, everyone. I'm Jamie Wittenberg. I'm the assistant dean for research and innovation strategies at the University of Colorado Boulder libraries. And I wanted to start by talking a little bit about what happened before I got to CU Boulder in 2020. So please ask me about the dark days before June 1st of 2020. We've been contributing to Folio for quite some time. We had some representation on the Olay board, and we've been contributing half of a developer to Folio Development for a couple of years now, starting in 2017. I think it was actually my first day on June 1st of 2020 that Paul Muller, the librarian who became our Folio product owner, came to me and said, welcome to CU Libraries. We have to figure out what we're going to do with our ILS. You know, what direction do you want to take this? And I said, well, first of all, tell me a little bit more about the Folio project. So I'm new to the Folio community. And, you know, our digital strategy in general at CU Libraries is built on, you know, this premise that our infrastructure in our libraries should both reflect and advance our core values. And, you know, those core values are centered on transparency and openness and access. And that's the primary reason that we made the decision to move to Folio for our LSP. One of the decisions that we had to make in 2020 when we were grappling with what we were going to do next was, you know, is this something that we should do by ourselves or is this something that we should do as a system? So at the University of Colorado, we have five libraries across four campuses that are sort of administratively separate units. CU Denver, Anschutz, our medical campus, Colorado Springs, CU Boulder, our flagship and the CU Boulder Law Libraries. And our approach to thinking through Folio implementation and adoption and collaboration was as a shared service system-wide across all of our campus libraries. We have an internal program that I've highlighted here called Financial Futures. And that's essentially a campus program at CU Boulder that enables individual units to apply for seed funding for projects that will eventually save the campus some money. And our approach to Folio implementation was to leverage the multi-tenancy of Folio to make a case for a Financial Futures proposal. And we wrote an application. We spent much of 2020 doing that together across all of our campuses. And I submit it to our CFO with letters of support from each library in the system. In late 2020, we were notified that we were successful and we received funding from the campus that is paying for our Folio developers until we migrate off of Sierra, which is our current ILS. So that's how we were able to have this kind of overlap between Sierra and Folio. Once we received notification that we had been approved by the campus to move forward with this project, we were able to hire some developers and make some decisions around what we were going to do for discovery. Unfortunately, it doesn't really work out alphabetically that Sean's before me, but MSU had already started their migration process and we're on the same ILS discovery stack as we were. So moving from Sierra and Summon, and we were able to have some conversations that were really important for us in setting direction for CU. So we decided to migrate to a shared Folio EDS instance with full commitment from our law libraries, but with continued participation and sort of some collaboration from our other libraries who at this point are still deciding if and when they are going to move over to Folio. In 2021, we also signed our contract with index data who are managing our migration. And we expect that in summer of 22, just about six months from now, we will be live with full Folio and EDS implementation. Good afternoon. I'm Tim McGarry. I'm the associate university librarian for digital strategies and technology at Duke University. And Duke University's history goes to the very beginning of the story. And maybe we should have done it in that order rather than alphabetical. In 2008, before anything with the open library environment started, Duke University was one of the triangle research library network libraries that launched search TRLN, which was powered by INDECA, and became one of the very first faceted discovery tools used for library catalogs. And this really set the vision and the strategy for the Duke University libraries and thinking about how we wanted to approach integrated library systems and library services platforms. And through that process and through other conversations that Deborah Jacobs had had with leaders around the country and leaders within Duke, they launched the open library environment in 2008 through support of the Andrew W. Mellon Foundation. And so we had a year-long program, an investigation program about what we wanted to do as far as transforming integrated library systems and creating open systems. And eventually this became Ole. And while I wasn't at Duke at the time, I was part of this process when I was at Lehigh University. So it goes, I've been in this from the very beginning. From 2009 through 2016, Duke University hosted a number of grants that supported Ole and through its various generations, which you've already heard a bit of, particularly from Elizabeth's talk about the various generations of Ole. And in 2016, as you remember, Folio launched in partnership between Ole and EBSCO. And Duke was still hosting Mellon grants to support Ole. And we wrote one final grant with the Mellon Foundation to transform our support from Kuala Ole into Folio, which just ended last year. In 2019, we circled back with our Triangle Research Library partners on open discovery and we launched Tear on Discovery, which we moved to a Blacklight implementation. And so we found that to be, again, still continuing to be our philosophy of doing shared discovery tools within our most local and prized consortium partnership and continues to represent the philosophies and the vision we have for open library systems. All along the way, we were keeping tabs of Folio. We were contributing, not only with the grant hosting and developer support that we had internally, but also through various special interest groups and community leadership. But we weren't quite ready to go live as quickly as our peers have been. And we still have realized we have a number of analog workflows and library collection strategies that require us to wait for a little bit more functionality to come along. But we decided we wanted to make progress iteratively and so we adopted an approach to implement different modules of Folio as we felt they were ready and as we felt we could implement them prudently. So, like Student University of Chicago, we didn't have an electronic resource management in the past and so we felt that moving to Folio ERM was our best interest and in fact it was one of the best decisions we probably made in a long time for implementations because we were able to get a jump start on not only learning the Folio system, but also building in workflows that we had really been struggling with for many years. And then this past summer, in advance of returning students to campus full time, we implemented the Folio courses module and the Folio inventory modules so we could start to continue to build on our Folio implementation. And this has been an excellent continued iterative process for us to implement Folio. We have a goal of completing our implementation of Folio by the summer of 2023. We're going to continue doing this iteratively. And what I don't mention in this slide but I will say out loud is we are hosting with index data as a service provider and we will be engaging with index data starting in early 2022 for our project management of our full implementation life cycle. Good afternoon. I'm Sean Nicholson, associate dean for digital initiatives at Michigan State University. We're a relatively young partner in all this. Our journey begins in the fall of 2019 where our dean of libraries authorized us to move forward with an RFP to replace a innovative Sierra based ILS. By 2020, we had a recommendation and a leap of faith to go with Folio, fully believing its mantra that the future of libraries is open. And we appreciated the modular nature of Folio and believe that would fit our implementation path. Beginning in October of that year a whole structure was created to manage it locally. But we also contracted with Epsco. And I think it's important for me to mention here while we had been tracking Ole for a while, it was the entrance of some major vendors into this market. And as Simeon outlined in our opening that multi sort of approach where there's vendors, there's community involvement, there's individuals creating modules that might be on the edge. That's what tipped it for Michigan State to go forward. And again, because it was modular and unlike our friends at Chicago, we believe that we must go at a fiscal year. But we singled out the finance and acquisitions modules and ERM to go live in July which corresponds with our fiscal year. But could set aside circulation and cataloging the two areas of the LSP that we felt were most wanting per our needs. We talked gingerly and hushed tones about going live with those two elements, the pillars of Folio and this time frame of this year. But after our assessment, I think Simeon said it was reasonable. I don't know if ours was reasonable, but we did make the decision to postpone. We are now targeting moving forward in June of 2022. And we're currently on Juniper Hot Fix 4 and have been successfully migrating with each software release. Those of you that are new to Folio, their software releases correspond with a set of flowers that we're going to be moving forward with. So we'll be moving forward with Kiwi, which I did not know was a flower until I joined the Folio community. I thought it was a bird. But we'll be moving forward with that in January. And the other thing I should point out is as an EPSCO client, we're going to be one of the first to be moving forward with our data and our full inventory is looking at a little over 11 million items. And so the bottoms, second to the bottom may upgrade to Lotus and Cutover. What we found, there's a very nice roadmap for the flower releases of the software, but we have a little bit of a slippage and I've mentioned before we're on Juniper Hot Fix 4, which is a critical element. So we're playing this by ear about our migration pattern because we are targeting Lotus as some key features for our library. And we've been very fortunate that our campus has supported us financially. We've been able to do Folio and committed to our partners at EPSCO to help host and do some project management for us. But we're also maintaining our subscription to Innovative Sierra. And without that we would have been pushed much too fast for not only the technology, but the psychology of our library. And I think we might get into that a little bit later in the Q&A. So the ordering did work out for Stanford both alphabetically because I believe we're last but also chronologically because we are the newest institution, at least on this stage, to jump towards Folio. We've been running what's currently Symphony for about the last 25 years and it actually works. It is not a house on fire and so for us the decision to first explore and then move towards Folio is because we see this as a good strategic opportunity and the timing is right. Around 2018-2019, as with many of the other institutions on stage, we had our eye on the ILS market and in 2019 we said it would probably make sense to organize an investigation and exploration into Folio. So we formed a steering committee at that time and basically spent the next year monitoring and observing how Folio worked as a software project and as an open source community. In 2021, so at the beginning of this year we stepped up our level of intensity to do a more formal evaluation, formed a campus-wide steering group with the idea of taking all of the coordinate libraries at Stanford into a single platform with harmonized processes and most importantly a harmonized user experience with loan policies and discovery experiences, for example. And in Q3 we actually made the formal decision to go. We had sort of been expecting we would go that way the entire time. We found nothing that surprised us and once we pieced together the things, all the individual elements we realized it was doable. So we're not rushing this because we are looking at this as a chance not only to do the system migration but also a re-engineering of our own processes and practices internally. There's a collective sense, especially among our technical services unit, that rather than managing our current ILS perhaps it has managed us and we have processes and practices that we're no longer sure exactly why we have them, except that's the way things work. So it's our intention to go through in a very methodical way and harmonization with the other library units on campus to really come up with an enterprise platform. We are expecting to go live on originally it turns out at our fiscal year cut over in 2023-24 and so right now that is just under two years away. And I think one of the things that we're looking at is we're interested not in a drop-in system but something that will grow and evolve with us. So we're looking the convergence of physical and digital we think is one of the most important aspects of the ILS. We feel like we've been unable to achieve some of the things that we would like to in our current platform. We're looking at things can we describe datasets or maybe either link compliance with data usage agreements for research datasets or link out to systems that do that. These are things that are difficult to imagine in our current environment. From looking at Folio we think this is completely feasible although it's not there on day one but we expect it to be there over the next. We're looking at this as a kind of a ten-year journey. So that's where we are and I think we can turn it over to Q&A now. So we envision this a bit of a hybrid here. We'd like to start with sort of a raise of hands or a hoot or a holler. How many of you are here just because you're curious about Folio? And how many of you are seriously thinking about moving to Folio fewer? Are you raising your hand? I thought you were. And then are there any people in the audience that might represent libraries that have commenced planning for Folio implementation? Looks like two maybe that could be up here on the panel with us. A select few. An elite. So we imagine this is a bit of a hybrid. I'm going to act somewhat like a discussant and engage the panel but we also want to engage you because we want to hear your questions. So be starting to formulate them and then we'll start the panel with this question. How was the idea seeded on your campus and how did you build support? And we'll start with Chicago. So as I described a little in my history of this, I think that the idea was seeded partly because we had already made progress and Folio was where Ole was going and it seemed like a natural move for us but as I said we actually did stop and say we should step back and make sure that we really all are in agreement that this is a direction we should be moving. There were many things that had been very rocky about Ole and so I think we really felt we should seriously consider what all of our options were because we saw that as a way of making sure that our staff really had a voice in committing to the idea of a development system, an open source system but I should say before we were involved in Ole we had been a horizon library and we were development partners with Horizon called LDMS which had been built in-house back in this was before my time but I want to say the 70s or 80s it had been around for a long time so I do think that culturally this was a really good fit for us we always have been interested in having a hand in that development so I think if you're coming from that environment this fits very easily and maybe some of our colleagues may have come from a different place and may have a different way of approaching what it means to get that buy in. Tom from? Yeah so I think I described it a little bit there's sort of a pent up urge to move to kind of a more flexible or evolving ILS and as we were watching the marketplace it seemed to us that Folio was something that was very promising technically but also from a community basis and so we just started by dipping our toes in the water talking to people attending meetings and then we went kind of ankle deep then knee deep I guess we're about hip level at this point the I guess from our experience the more it is an open source product and an open source community and if you're hoping to figure things out by reading documentation or glossy PDFs on the website you're not going to get very far so for us really kind of going to some key meetings and listening in on all of the meetings which are open has been instrumental in trying to figure out where things are and how we might work in the community. So on that Jamie could you talk a little bit more I think your multi-campus aspect is important here. I'd be happy to I mean you know I can't speak for our other campuses I can only expect it from CU Boulder but I think that for us it was really an opportunity to think about how can we shape the future of our own infrastructure collaboratively as a university and it is really about that focus on what the kind of LSP of the future is but there were also financial factors and you know when I was talking to some of our other libraries I mean the value proposition you know from a practical perspective was centered around this financial futures proposal and so there was a cost element there as well where we said you know if this is something that we all want to contribute to and we think we can do together you know it can save us x percent on our costs as a university and I think that that was important for us as a public university in a state institution we're always trying to do better by our state so that was a factor as well I'd like to switch gears a little bit and Simeon you're the furthest along of the institutions could you share with us some of the pain points or considerations that folks out here might be wanting to think about as a consider going live but I don't want you to focus only on the negatives but I think sharing some of those will be illuminating things well I think for us it really was a case over this last year or two of tracking what's the reality of where's the project at you know we brought into the vision the architecture the notion of community and open source that's all great but at the end of the day we do need a system that works so for us part of the decision to go live was about what is it we really need to go live that allows us to take a step forward onto this new track where we will get everything we want sometime down the road and we did go right on the cusp of folio being sufficient for us to get by it's an enormous credit to our staff for managing to do this one for managing to make the assessment carefully enough that we didn't get it wrong and crash and burn on July 1 that would have been bad and also to our staff for putting up with a system that was only just ready so initially we had some performance issues which we had to work through with EBSCO to make sure that we got say circulation performance that was okay and things and there have been a number of improvements since then and now that we look at the pipeline of future releases we're expecting to get a lot more the end of this week and we'll get more with Kiwi and we'll get more with Lotus so we see a path to where we want to be but we did opt to go at the earliest opportunity I think I guess the advice for people looking forward is take a realistic look about where you think the project will be and you decide next summer I guess if anyone's thinking about it now you're thinking about summer 2023 where I think it probably will be in great shape by then and Tim I think we would appreciate hearing from you you have some elements live and some you've chosen to postpone maybe up towards the two years could you talk a bit about pain points and some advice sure we have a little bit of different approach than Stanford has taken as far as the way that they've examined their implementation strategy and also the way that we do things we have quite a bit of autonomy within our departments to set workflows and I think I definitely agree with what Tom had shared earlier about the ILS sort of directing our work rather than the other way around and it has required us to think a little more carefully about what it means to do our work at scale in a different workflow so we did take advantage of moving to some of the areas that we didn't have before like ERM because it was an opportunity for us to use a new product for us to jump into it without a workflow that's been already defined for 20-25 years and so that was really helpful we also spent a great deal of time investing early days of folio with the special interest groups we volunteered some people to be project owners and so for in some regards we have seen where the deepest parts of the sashes are made and so for us there was some reconciling of what are the things that we know and how deep we know those and then how can we step back and think about a different process for implementation and so that's been an important process for us as well one of the things that one of the ways that I'm trying to change the narrative and think about the ways that we approach our implementation has been to break down this idea that just because it's a next generation library system because folio is a next generation library system doesn't mean it's actually going to do everything we used to do in the past so not everything is backwards compatible so that means we need to think about what we take forward with us and even re-examining back from the time we went from DRA into ALEF many years ago we force fit a lot of those things in there that doesn't mean we're going to be able to force fit those things out of ALEF and into folio so we're taking a very careful approach to some of this so you in the audience you've heard some level setting, you've heard some peaks and some valleys here we're curious if any of you have any questions, I think there might be a couple microphones if you want to step, yeah please I think over here to my right first yes Hi, Cynthia Schwartz from Temple University several of you mentioned that you have developers that you've dedicated to the project but then you're also working with either Index Data or EBSCO so how much kind of in your affair assessment how much active developer work is required from the institution versus you know having the hosting services let's go alphabetically so we have developers that are working on our own integrations that we have built around our ILS systems, we don't have developers currently that are actually contributing back to the project so it's not something you have to do, I think that one of the questions here in general is how we all think about what our how can we best commit to the project and we did at times have actually had two people who were acting as product owners but never developers, there is a process to become a developer on the project to actually make sure you understand or to developing good code and we just didn't have the bandwidth to do that so not necessary but it was absolutely necessary for us, we have a lot of things that we had built around our systems what we kind of call our helper apps and such and we've had a lot of developer time doing that but that's going to depend on whether you have that type of thing or not and we also I should say had built that around Olay so we had very few partners we were one of three institutions that had ever gone live on Olay so we also didn't have the same kind of community that might have been working together to build integrations so in some ways that left us more on our own for many of those I guess we did it alphabetical by institution so Cornell has over time contributed various amounts of developer effort to the project and Elizabeth mentioned that's not essential there is a formal membership model as part of the government structure of Folio now where they would very happily take a pledge of developer effort or a monetary contribution or both I try to think about what does it mean to have a sustainable community project going forward so when I think about how much does Folio cost I think we've got some amount that we're going to have to pay for our own installation to be supported whether we do that in-house or whether we as we do at the moment choose to have a vendor do that and then I imagine well what should be the level of our commitment to maintaining this community project so at the moment we are contributing one FEE that's half an FEE of product owner and half an FEE of development to the project so they are not doing things directed by us they're directed by the community we also have had a larger contribution in the past but that was to help the project get started more and just as Elizabeth said we obviously have developed a work for our own in-house other projects since we have our own discovery system at CU Boulder we have two full-time developers that are working on our migration specifically so we had been contributing half of a developer since 2017 and this year we made the decision to not make that commitment and to make other kinds of financial and in-kind contributions to the project so that we could focus all of our effort on our own instance of Folio however our junior developer on the project as part of his onboarding we thought it would be a good idea for him to contribute to the Folio community and so in practice we actually still have half a developer that's contributing to the community and I asked him about how that was going and he said that it's been a really wonderful introduction to the project and it served the library really well in practice we also have other developers that have been helping out with this project and I'll say from a staff perspective we have I would say 20 to 30 people in our libraries staff and faculty who are putting a lot of effort towards this migration so this is a very resource intensive migration for us and we're all really focused on making sure that when we go live it's as successful as possible so it's definitely a dedicated project for many people in our library yeah Duke we hosted all of the developers that came through the Mellon Grants that were wholly paid for by the Mellon Grants and they were fortunate enough to retain one of them for our own position and we got to have him for about a year and a half before he moved on to another opportunity we don't have any developers right now working on the project at the moment we're just about to search for that vacancy and like Jamie said we're probably going to encourage that new developer to take a half time role and jump into the project and on board that way so that they can get involved but I agree very much with Simian's context of how to think about the cost of the project and we're going to approach the ongoing sustainability of FOLIO the very much the same way of any other open source project whether it be Simbera or D-Space or Blacklate etc but I will add one nuance to the answer that's outside of the programmer perspective and that is we took the initiative to invest in business analysts before we started our FOLIO project our investigation of our peers that went with Alma and saw what their process was like convinced us that a business analyst role would really be beneficial to our staff particularly as we're trying to go from one system to another because having somebody do their whole day job spend some time contributing to FOLIO and then also prepare for an implementation was going to be really taxing on those individuals particularly some individuals who's only known this work for the past 20 years that they've been at Duke and haven't known anything different and so it was really important for me to invest in some business analysts who could be thinking about FOLIO and the workloads at a higher level could be making some of these translations between this is the way that you do your job in one system this is the way you're going to do your job in another system these are some inefficiencies that we've just done because this is the way ALEF has worked these are some efficiencies we're going to gain this is how efficient it is in ALEF these are some inefficiencies as present for FOLIO but help us to do it better in the future we hear some ways that we think could work out that was a really important step for us and I think it's going to create a great deal of sustainability at Michigan State we committed to one FTE of engaging the community and so that person's full role is out in the community and works on a team called ThunderJet and it's primarily focused on acquisitions and the financial areas which I indicated in my earlier comments was our key priority we also have about I tried to do the math here I'm going to guess it around a quarter FTE for our local integrations of development time but I also wanted to echo a couple of my colleagues' comments we also contribute financially to the community and that hires developers and but also pays for infrastructure like to Amazon and such but we believe that that's an important part of our role and then this idea of the capaciousness of what a developer is our staff are doing an amazing amount of work whether it be just creating lists of content to send to the migration team things like that that are maybe not typically thought of as developers but I want to acknowledge their time and effort because as Jamie indicated it is a significant thing it underlies all that we do as a library so at Stanford we've hired an incremental folio the title was folio developer at least that was the shorthand when we made the hire they're going to be allocated 100% on our implementation through 23 and after that point we think they'll be in a position to step forward into the community based role and then of course we've got a bunch of other developers who will be working on the integrations and the local implementation so partly that was because we feel as relative newcomers to the community we're not really sure what effective contribution we can give or where the greatest priorities will be so part of it is just learning and coming up to speed ourselves there's one big caveat and I'll just slip this in because I don't know if it'll come up and then the other questions we have another team for the last several years we've been part of the LD4P grants and working on linked database cataloging we're at the point in that series of projects where we figured out that we're linked data to really take off in the library descriptive environment it needs an integration with an ILS so we currently have our full our full development team that's working on that is putting half their time into future enhancements for Sonopia the linked data editor and the other half of the time is actually working on a integration right now with folio which is an awesome example of kind of the openness that comes with an open source software platform thank you for being so patient all of this is really really fascinating my name is Cara Watley I'm at Caltech and I didn't raise my hand earlier because we've actually already migrated and I didn't realize that everybody migrated to align with their fiscal year but we did so we came up at the end of September and it's it's amazing like how much of our experience has been echoed there and I'm really interested in and kind of the things that you were just talking about you know sort of where you're putting your development time and kind of where you're thinking about continuing to develop folio one of the things that we've been working on is control digital lending and I thought I heard one of you mention it earlier in the panel so that's what I was interested in is hearing you say a little bit more about your thinking of CDL related to folio thanks I guess I should answer first since I think it was me who said that so as far as I'm aware there is no concrete attempt to implement CDL directly integrated but as other people have said the extensibility of folio is one of the reasons we think it's a good basis going forward and especially this sort of dealing with both both print and digital in the same system I just put it out there as an example of something that would have been say outside of the purview of a traditional ILS but fits within the notion of a library services platform and I can also add that in fact we are in the process of installing what you've done for CDL and it is exactly we're very interested in that we had been had a test instance of another CDL solution but we're much more interested in one that could integrate with folio and that to us was more future looking and so we're just now in the kind of implementation test phase of it but I think that it is also a really good example of how and why we went for this platform because of our interest in being able to grow it into new areas like that and I want to point and link data as well that was really one of our interests at the time was it seemed to be the one system that was looking towards being able to expand in those ways I can put a little bit different head on at the moment and say as the two more weeks left as the chair of the reshare steering committee that reshare is going into the CDL development perspective and reshare is a software shares some infrastructure common infrastructure with folio so not only does that speak to the extensibility of folio and underlying software but it allows us for having different kind of modularity that can do connections so I'm happy to talk with you afterwards about that. Another question over here. So one of the things we often don't talk about in presentations like this and I will be myself I'll call myself out is what did you have to deprioritize when you took on this work? Are there certain things that you wish you could have done instead that maybe you had to push off what was the consternation that then occurred because that always occurs when you have to have to deprioritize things and I'd love to hear that conversation and again I've done these panels and I am guilty of not talking about that myself. I can start because I feel like we have had to deprioritize a lot I mean when you make a decision to do something this big you have to deprioritize or else you will have a lot of very unhappy librarians that have been overworked. My product in our portfolio I think I said to him are you okay with just doing this for two years? I mean this is pretty much all that you're going to have time to do and you know we sort of made this commitment to each other okay this is what we're doing and you know he's been with our library for a long time and he's tenured and that matters right so I think that just the pressure on people's is part of it but we've also put off migrating to other open source products so we had plans to migrate our digital library to San Vera we still are planning to do that we're currently on a proprietary platform and it's had to be sort of pushed back because this was our highest priority in our library so certainly some things had to be deprioritized and we're continuing on with that platform some of the same problems that we've always had with that platform but you know when we look at how far we've come with Folio we think that we've made the right decisions here and we think that our prioritization of Folio is going to pay off for us down the road. So I'll start with there's just the opportunity costs that are lost and so there were some bespoke applications that were in our planning cycle and when we devote an entire FTE developer to the Folio community that means you cannot do those things so we deprioritize those and identify them and so they need to wait but one thing that we're being recorded right acquisitions has suffered we've had to deprioritize some of the high level rapid turnarounds we pay our bills but they take a lot longer frankly because some of the Folio's I'm not an acquisitions person but my understanding is some of the functionality of Folio's acquisitions and the finance modules it's a struggle to get through those and that's hard on staff who had prided themselves for so many years of being on top of all that so those are two areas that I can point to pretty easily thanks for your question and I would also add to be honest I think we've we've sacrificed a certain amount of just production work and I would say that in light of really seconding what Tim said about a business analyst we don't have one we really I think have suffered from not being able to fill a position like that and we've had the advantage that our staff having been involved very recently in the move to Ole and being involved in the development are able to actually do a lot of that work and they don't need someone to help them think through that but it means they're spending their time doing that and that means they're not able to spend as much time doing doing their just regular work and we've had to really look at balancing that and so I think the more you have some staffing based on just to do the work of the migration and the planning the less that you have that but we've really been torn between the two partly because of open positions and such I see we have one more question but I want to just add one little twist to the answer which is we'd be prioritized folio in our processing planning at Duke really because we recognize that as the ones who started this whole thing we couldn't really back out for any other reason besides total failure which we didn't see obviously in the future and we certainly didn't want so we chose some other priorities first we chose to do our discovery layer first we chose to do our triple migration next and we knew that we had some time to be prioritized folio and do that a little bit slower I'm very sorry but we have reached the time I'm sure the panelists will be happy to chat with you with your question as a de facto discussant I hope you would join me in thanking the panelists and myself so thank you very much for attending we look forward to continuing the conversation