 So we're going to begin. Thank you all for attending the Cornell University case study Drupal as a centrally brokered web platform. I'm really excited to be up here on stage. We'll get into introductions in a second. But just a quick overview of what we're going to talk about to make sure that you're in the right room. And this will be interesting for you. As many of us know, but maybe many of us want to learn more about, university IT organizations face a distinct set of challenges when trying to adopt open source technology as a kind of a campus-wide solution. Often, you see lots of organic adoption, which is wonderful in part of how open source gets traction. But when you start thinking about it as a real official thing for everybody across campus, it gets to be pretty challenging in ways that I think are very unique to universities. And that specifically comes down to the fact that you have to support such a wide range of use cases when you want to try to provide a universal service to campus. That means large sites, small sites, technically sophisticated people, technically people who need someone else to take care of the details. And I come from an agency background. And it's a bit like Shannon Rand talk about being like an agency on campus. One of the great things about being in an agency and in business on the open market is it's really easy to just not bid on a project or to say no to an offer or, in an extreme situation, fire a client. These are things that are hard to do when you're a central services organization for a university. So that creates a challenge. So there's a lot of things you have to cover. You have to meet a lot of different use cases. And at the same time, there's this incredible drive to standardize and economize. Because you want to be a frugal with your resources. Budgets are always a concern. And you're trying to figure out how to make things be easier to support over the long haul. So in this context for the web, Drupal presents an enormous opportunity but also some specific challenges. And as I think we'll learn in this presentation, figuring out what to standardize, where and how is the key to finding success and with Drupal on campus. And a big part of that in my opinion and in a very self-serving opinion is that flexible and scalable infrastructure is a key to being able to figure out what and where to standardize and have a same life bringing Drupal to campus. So that's what we're here to talk about. And to introduce myself, I'm Josh. I'm a Pantheon co-founder where I'm head of product. Longtime Drupal Evangelist started an agency way back in the day called Chapter 3. I'm at Atlantis Josh on the internet. But for the sake of this presentation, I'm going to move my Pantheon guard because we're here to talk about Cornell. And with that, I'll turn it over to my co-presenters and we'll jump back up later. Thanks. Ooh, thanks, Josh. Hi, I'm Ryan, I'm the hosting engineer and the customer web development team. I helped architect the Cornell stack, which is basically our lamp stack that we use on-premise. We've been using it for about four or five years now and I presented at our recent Drupal camp back in last October and we're having another one this October in case you're in the area. Hi, I'm Shannon Osburn. I'm the assistant director at Cornell. I work in central IT and I run the web development group. As Josh mentioned about firing stakeholders, I don't get to do that. So we're a cost recovery group within central IT and I'm one of the organizers of our camp. So I'm going to give you a little bit of history or a little bit of context about us and how we fit in at Cornell. So I've been at Cornell for 17 years now, mostly in the web area. Cornell is huge but very, very diverse in the IT space. So there's central IT and then there's different pockets of IT all across campus. Our central IT covers anything, you could be in the voice and data group, you could be in my group, the web group. So mine specifically though is a little unique where it functions much like an agency. We are our business within university. So we are cost recovery. We offer an array of services that we'll get into in a little bit but we really do function just like vendors you'd see anywhere outside. So to give you a little context of what my group is made up of, initially we started with the web design group. So it was kind of small and we had a bunch of project managers, web designers, web developers. And then over time, we had these other areas in central IT that were very distributed. We had a custom apps group and we had a hosting group and it never really made sense on why they lived not even in separate groups but under even separate directors across the IT. So over time, we took the web group and the custom apps group and we melded them and we started realizing, oh, to have deeper programmers, that's awesome, that's really great. There was still a missing link though. So then we, and maybe some of you can kind of understand, sympathize maybe even with this, we got into a lot of it's broken. Well, it must be the hosting provider's fault and then the hosting provider would say, no, it's your code. So there was a ton and ton and ton of that. Well, that kind of diminished once we invited Ryan and the rest of the hosting team into our umbrella group which is called Custom Development. So as you kind of meld and mold your teams together, you try to identify sweet spots. So we had developers, designers, we had folks specializing in PHP and then we had hosting support folks that did lab stacks and we had a very big technology platter outside of that but the sweet spot for us was Drupal. So I don't need to sell you on Drupal. I think everybody's here because they believe in Drupal, it's good. But specifically for higher ed, I think it's really appealing that it's open source. Higher ed's also about community. So really the ability that you can go out and Google and find resources or talk to your peers and find resources is really advantageous for us. The flexibility to customize in a minute, I'll talk about our proprietary system we were using. So we really did not have a lot of room to customize it. Obviously, Drupal, there's a lot of customizations. And then outside of that, it really, we would take on projects in the web team for the cost recovery side and somebody would describe to us an app that they wanted to build and they'd describe to us a brochure website they wanted. And probably many years back, we would have said, okay, we'll build you your website and we'll farm you out to the Custom Apps group and they'll build you your app. But Drupal, obviously, we can bring both together and once we started doing that, business and our team actually started skyrocketing. So that was pretty good. So stepping back a little bit, the early days of Drupal adoption on campus, it probably started in the library area. They had some sites, they were focusing on Drupal. We're so distributed at Cornell, unfortunately that we couldn't even tell you who else had Drupal back in the early days. There was no hosting specific Drupal provider negotiated. It was pretty minimal. We were using our proprietary CMS across campus. It was a little interesting at the point that folks were starting to dabble in Drupal. We had reached a point where we couldn't find a vendor that we could hire to work within the CMS we used. We would do a Google search on the, try to find some kind of documentation when we hit a roadblock. We came up as like one of the top three hits. That was horrible because there was nothing out there and we certainly weren't the experts. So partially because of that, and then a few other reasons, we started seeing community adoption. So there was kind of a push of cloudification on campus so people were starting to look at cloud tools. Folks were trying to move away from the proprietary CMS that we had. And so we were starting to see Drupal sites go up all around campus and then our team had started dabbling in it as well. We hit a tipping point. So we kind of got to the point where we had this proprietary CMS. We were all sharing the cost. Well, once half of you leave, there's still that cost to be shared and the vendor doesn't say, oh, let me charge you less because some of your friends left. That doesn't work that way. And if anything, the vendor started charging us more because I think they could kind of see how the market was changing and they wanted to still have a footprint. So at that point, it kind of became clear to us we needed kind of a phased retirement plan out of that CMS and we had to move to something that we deemed was advantageous for us. So that led to a lot of central planning. Ryan will go into more details on this but we did an RFP with Wild Medicine and at that time, this was several years ago, Wild Medicine ended up going with Pantheon and then we ended up signing with Acquia. However, we've signed with Pantheon as well. Our team really focuses on brokering the right choices for campus so we tend to offer them a platter of choices but we try to make sure that it's meeting all their different needs. So Josh talked about different sizes of sites and different budgets and just different needs altogether. So our job is really to put something in place for them that we believe is the best to breed and hosting providers so that as we talked about early adoption, I didn't mention but people were just hosting wherever. We saw a lot of Drupal sites on our lampstacks. We saw a lot of faculty having their students host it in a box somewhere in a room and then everybody forgot about it. So it was really time for central planning to figure something out. Thanks, Shannon. And so one of the things that I can offer from a perspective standpoint is working with a lot of stakeholders in higher education and probably for a lot of you in the room, this story sounds familiar, right? These are the common challenges that often people in higher ed encounter and that represent a challenge when you try to take Drupal from organic adoption to a centrally brokered solution. And so I can speak to, for instance, our good friends at the University of Pennsylvania, a fellow Ivy, they had a very similar pattern where there was a longstanding Drupal kind of practice within the College of Arts and Sciences and the business school was doing its own thing and they were like, way, they were off on their own island and in their own world and the communications department had a specific need because they were launching some high profile websites and we ended up working with them over the course of about two and a half years and it's still an ongoing process to bring all these stakeholders to the table and iron out what are the truly common things that can be shared, where do you need to have local or federated control, what's the governance model for figuring out how to actually deliver Drupal in a standardized way as possible across campus and it's just one of the big challenges. I think people often will use a term like herding cats which I think is a little bit, it's a good metaphor because visually it's like, you can't actually do that but I think it also is a little bit dismissive because it's hard work and it actually has to be done and when you can do it, when you can actually manage to get all the people in the room and have them talk out like their needs and wants and everyone realizes that oh actually, we all pretty much need and want the same thing. We just might have to collaborate a little bit to get there together. It can be a very powerful catalyst for change. I've been in a number of rooms where the groups of stakeholders come together that even though they live very similar lives on campus, they don't actually get to talk to each other all that much and it's a really wonderful thing for them to realize that in their pursuit of Drupal, they have a lot of common interests and they can reinforce one another. Another challenge, as we've remarked before, is sites of all sizes. So a university when they're considering Drupal as a solution, they need to be thinking about Drupal probably for the largest use cases, such as a flagship website or a high profile professor or research website that could see spiky interest from the internet. You might have a department on your campus that does things that periodically makes them internet famous or they get slash dotted or the like. On down to the far other end of the spectrum where the crew team probably wants a website and they should have one. That's part of modern life. The crew team deserves a good website and maybe they should be using Drupal for that website and the challenges are that the crew team versus the provost, they're very different types of customers and having a scalable infrastructure that can meet those different kinds of needs on a common platform really helps you out a lot because one of the things you're fighting against at a university is this constant entropy for things to fragment apart. So our good friends at Arizona State University, they have hundreds of sites that they're running and they really do span the spectrum from extra large to medium to sorry, extra large to large to medium to small to maybe extra small and it's a really powerful thing for them to have a common set of practices that they use for those sites even though they might be very different in terms of how they are scaling. It just makes their lives much less complicated. And finally, when it comes to budgets, you know, as Shannon mentioned, Cornell operates on a cost recovery model which means they have to kind of bill for their services, they have to bill for the any provider costs that they've passed through, they have to bill for their time too on some level and this is where it can become a really big challenge for a university and for an IT administration where calculating the total cost of ownership of Drupal. You know, we say like at the beginning there's a bullet pointing that there's no license fees which is great, right? Like we don't want to go back to the era of proprietary software and just paying for the privilege of installing something but just because there's no license fee associated with open source doesn't mean that it's free. The cost of open source is that you age while you figure out how to make it work. And so, and that's not free, right? You know, that's the time is money, hey. And at Pantheon, we are very lucky to work with our neighbors across the bay at University of California at Berkeley. Early on, you know, they worked with us and really gave us the benefit of working with us when we were a much smaller company to help us understand these needs. But one of the things that drove them to that was they actually sat down and did the math. They had servers on campus. The servers were effectively free in the same way that electricity was free on campus. And they had a good Drupal expertise on campus and they had some ideas about how they could build the system to manage all the sites on campus and they did a prototype of that whole thing and they put it all together and then they sat down and said, okay, so how much time does it take us to deploy a site? How much time are we spending managing updates? How much time would it take us to onboard if we're gonna bring in some of these sites that are already running around campus? Let's just do some back of the envelope math. And what they figured out was that with the people time factored in, the total cost for them to do this with their own stack and their own infrastructure would have been really untenable for campus. They weren't gonna be able to hire 10 new people to manage the stuff at the scale that they had to for the university. So they did a little research and they reached out to us and we were to help them with that by allowing them to leverage their people time to much larger effect than they would have been if they were just working with their own technology. So total cost of ownership, not just top line cost for licensing, you can zero that out with Drupal or the cost of hosting if that's something that's recognized or passed through. It's the cost of the time it takes to operate this stuff that people really struggle with and without good tools and without good practices in place, that's the cost that can spiral out of control very rapidly. So to talk a little bit more specifically about how Cornell University conquered all of these challenges or is conquering, let's just be a little more honest. You can take it all right. Definitely haven't conquered all of them yet. So Shannon started out with a really good slide where it showed her three groups, the web design, web building and then the custom apps and then the little hosting group that came along a couple years later and that group started out with three people and we're now down to one. And we built these great VMs that are used on-prem, we hosted a bunch of websites out of it and being one person team to maintain these VMs upwards of 200 of them can be a little challenging. So Shannon and I realized after we got with Acquia, web hosting, the hosting environment is not where we should be. We're a web team. So there are companies out there that are doing this like Acquia and Pantheon and that's where we need to be looking to put our customer sites. It just makes more sense. A lot of times it costs a lot less for them to host there and they do it a lot better than what we can do on campus. Then that frees up my time to do fun things like project management and play around with Drupal. So it's kinda cool. So the Acquia contract came on through an RFP and funny enough Shannon's team wasn't really involved with that initially but that's a whole another story in politics going on. But so you're looking at what our customer is asking for. We looked at our current hosting, our little Cornell stack, what it can do. It does pretty well. It's still in use. We have a little dashboard. People can start and stop services. We have Git in there but it doesn't really work very well all the time. Dev test prod. People try to do that through different VMs but that kinda messes up your code migrations. Anyway, so those are the type of things that we wanted to make sure the hosting provider would do. And obviously Acquia does it and then so does Pantheon. So I started playing around with Pantheon in 2015. I migrated to really small sites. Went really, really quickly, very nice. The customers were super excited because their sites were actually faster on Pantheon and it was a lot cheaper than hosting on-prem. So now that we have Acquia and Pantheon we have a multitude of options for our customers. So then marketing the campus. As Shannon mentioned, campus can do whatever they want. They don't have to work with Central IT. They can just call us and ask us for recommendations. So we really wanted to make sure that Central IT was giving them the information they needed to allow them to make the decisions that make sense for their sites. So it actually happened kind of organically. Once we started putting sites on Pantheon even before the contract was officially signed to get the really nice discount, things, word of mouth started going around on campus. Departments were talking to each other, hey, they have a contract now. Get a discount or hey, it's working out really well. Go with what Central IT is suggesting to do. So that's how it's working. We also have our Drupal camp. The vendors can come on site, talk to the customers directly. The customers kind of feel more involved that way instead of Central IT saying go do this. It doesn't work that way at Cornell. Cornell is kind of like here are your options. You make the decision and we're here to help you. What also nice with the platform providers is they have a lot of support behind them. They have incredible documentation, stuff that we don't have to worry about writing because it's all their services and tools. The customers can do a search, they find what they need and they can go merrily on their way or they hire our team to help them with that. Finally, probably one of the really big sticking points was billing. How are we going to do this? Each platform provider and hosting provider are going to do it a little bit differently as do all universities do it differently. We don't really have the overhead to do a whole lot of accounting and build back. We had to work with both companies to figure the best way forward and I think it's working out fairly well. And then of course support. We have a broad range of IT people on campus and then we have some places that don't have any IT people. So we wanted to be able to support those people, all of them. So they should be able to do a self-service essentially, spin up a site, get it ready to go and then let us know when they want to go live so we can then build them back. Then we have the customers that are going to contact us and say please, I just need a website, please design it, build it, support it after it goes live. That would be the full service. We can do that really easily. We're familiar with the platform. We can spin up sites really quickly and get rocking and rolling and we'll have a site for them. And then we have that one in the middle which is kind of cool which is where my consulting part for hosting come in and we can sit them down, ask them about their site, what they want to do with it, what they expect to do with it and what their future looks like and then we can kind of say, you need to be living here or you need to be living there. So having the options and the ability to support developers who know how to do code migrations and use Git and all that stuff and then those that don't know how but can come to us to do that for them. So where are we at now in Drupal? Our group is supporting lots of Drupal 7 sites. We actually have one Drupal 6 site. We are not building any new Drupal 7 sites since probably October or November. New projects are all going out as Drupal 8. We have about, oh I don't know, I think we have 50 sites on Pantheon right now. Total and it's across campus. We don't support all of those sites but those are within our organization. The most recent really large site that we launched which we're really proud of is our new IT at Cornell website. It's a Drupal 7 site and you ask why? Well it was a really long project so it started out in Drupal 7 like a year and a half ago and it just, we had so much built into it and so much time and effort into it. It was just not worth trying to get into Drupal 8 before our plan go live. So it's pretty cool though. It's basically a custom knowledge base and we're really proud of it in our IT communications group. Did a great job with content. People can search for anything they need based or whatever they're looking for IT related at Cornell. So and we're continuously developing in Drupal 7. We have sites we need to support. People are asking for new functions, new swirly things on our website. So we will still continue to use Drupal 7 and build in it but moving to Drupal 8, we're pretty excited about this not only just because it's Drupal 8 but the two developer size of our groups, we have Drupal developers and we have those custom map developers. With Drupal 8 and using a PHP framework symphony, the custom apps group is really kind of latching onto that. It's like, that's cool, I understand that. It's not like the Drupal 7 way. So they're digging in, they're getting excited about it. You know, they're more accepting to a content management system now. So they're actually starting to contribute to building Drupal 8 sites. Then our Drupal devs who are still supporting the Drupal 7 sites, they might be a little jealous but their meeting I think is like every other week or something like that, with the custom apps team who's looking at Drupal 8 and they're comparing notes and they're being collaborative and they're kind of sharing ideas and like the Drupal 7 people are like, you know, you might need to do more Drupal like to this and this is how you should do it, not go like crazy custom code PHP things. So it's kind of cool to see that happen with our team. So we won't maybe be three circles anymore, we might be two. The other exciting thing about Drupal 8 for our group is we're working on a distro. So, thanksful to Pantheon who allows us to put custom upstreams. If we can get this Drupal 8 distro out the door, it's gonna be Cornell themed. So people will start a site that has a really nice Cornell logo that's properly branded. We'll have the common functionality that customers seem to always ask us for, for universities note of calendar, events, three or four content types, a slider, whatever it happens to be. And so those things will be all packaged up along with our single sign on packaged up. People can pull them down when they start a site on Pantheon and add a few extra content types if you need them or some content and you should be ready to go. So that's probably one of the more exciting things about Drupal 8 right now. We are also thinking about partnering with some of the other colleges and IVs in our area to make it broader and kind of more college friendly for everybody, but that's kind of in the work still. But along with that on the community side. So we have our official logo, that's our little bear. So we're very proud of that. So on the community side, we were a little slow going because everything we just went through, we had to get our arms around everything, we had to get hosting established, we had to get our team spun up in Drupal. So we didn't have a ton of time to say, okay, well let's take the community nature of Drupal and embrace it here at Cornell. So we're making progress finally in this. So a couple of things, we're on our fourth Drupal camp. So as Ryan said, it'll be this October 19th and 20th. That's been very good and beneficial for campus and we invite in other campuses, we don't make it specific to Cornell. Outside of that, we've got our Drupal SIG, which I think tries to meet monthly, but again, with a bunch of web shops, everybody's always busy, but we are trying to get a little more traction on that and keep that going. Outside of that, we've got an Ithaca Meetup that some of my group attends and we try to contribute to those discussions when we can. And then the most important things right now are the D8 distro that Ryan mentioned. I do have a peer web group that I work with, our group, Wild Medicine, Yale just joined and Princeton. So if anybody else is interested in talking to us about that, definitely let us know. We started meeting a few years ago. All of us are doing some of the same things at different universities, especially if we're all each cost recovery shops to some extent. So we try to leverage each other and share where we can. And then lastly, soon we'll launch, I think this summer, our Drupal community site. So we have this dream where we can share all of these great resources or any hurdles that we overcame and others can leverage from. So we'll try to share that broadly and would welcome any input from anybody once that's launched. I rigged it. So just a little bit of sharing. I have a question I promise, but first a comment. The worst question ever. So this was a really interesting experience for me to work with these two wonderful people in developing this presentation. And I think that they're very modest about what they've been able to do on campus. And just talking through their story of how things went, it's been a long journey to get to where Drupal can become a fully seal of approval applied. We have the right Cornell logo on the slide and everything else is approved on campus. So one of the things that came out in that conversation that we didn't really figure out how to make a slide around that I'd love the group to hear about is, can you talk about the work that it takes on campus to just get together like the design, the style guide, like the sort of the front end aspects of this. We talked about like the kind of the Cornell front end working group that's actually in use by people who are doing other web projects that aren't even in your group. So the branding you mean specifically? Yeah, just like the kind of like it sounded like when we were talking about this going from like there's the brand guide, which is like here's the right logo. But it sounds like there's this effort on campus to go from that to like here's a bootstrap based front end that could be used in many different contexts. So that would be the theme that we're hoping to pull together. So we're trying to, right now there's a brand book, they call it for Cornell. It's pretty minimal for the, basically here's a logo and here's six or seven different ways you can use it. So we are trying to pull together our theme with our new distro that would really kind of lay things out so that they end up looking great on a phone for people and so that they've got accessibility in mind, UX in mind, all those best practices in mind. Trying to pull that all together so it works for everybody is I think Josh said herding cats earlier, that's pretty much how that goes. So we're trying to also get that theme set up in a way that others can just take it and adapt it to them for themselves after that. Cool, I mean I think that's just a very cool thing to do on campus. So any real questions are welcome, but let's give a round of applause to everyone for the presentation. Hi, I actually went to Drupal Camp at Cornell this year. I work at RIT in Rochester and you had a great time. So anybody in Western Central New York, please go, it's a great time. You mentioned that you're running older sites in Drupal 7 still and newer sites are being built in Drupal 8. Are you pushing people to upgrade their Drupal 7 sites to Drupal 8 or are you just building new sites in Drupal 8? And if you aren't encouraging people to do the migration from 7 to 8, how are you planning on managing these Drupal 7 sites in the future? Sure, great question. And definitely a challenge for probably anybody that runs a web group in a university setting. So to be totally honest, we're definitely not encouraging anybody in 7 right now to say, hey, sign up for an upgrade project. We're so busy that we're just not ready to take that on. Plus I'd like to see us get several of, you know, a good handful launched in A under our belt before we go to somebody to try to sell them on something, I wanna be able to say, hey, look at these great things. We know what we're doing. We've got a distro, we'll save you money, we'll save you time and let's get you to 8. For me, that's our path forward. It's to get a good solid base, make sure my team's fully trained up in 8 and then go. I think because we're part of the university, the last thing I would wanna do is start that early, break trust with any stakeholders and have them be like, why didn't you just let me wait? So that's kind of the path we're trying to take there. I'm at a similar university where we've got central IT and we've got edge IT and trying to get those people to work together. It sounds like you're on that road. There've been any things that have worked really well and some things that didn't work well to kind of build that trust and get people to stop doing things that they're doing in their communities or their edge IT and bring it to the central IT. Yeah, that's a broad topic. So, I can tell you, good CIO leadership over IT really does help. So, separate from Drupal all together. I think that's really the only thing that I've actually seen. I mean, you can try a lot of grassroots stuff, but if you don't have a strong leadership that actually wants to bring IT together, everybody still tends to kind of hold back and just stay in their little kingdom. A couple of things that we have found works versus doesn't work is being a cost recovery shop anytime somebody runs into me, talks to me, calls me, sees me, anyway, they look at the, they're like, are you billing me? So that doesn't open doors, right? That doesn't really foster that sharing or community. So what we've tried to do is, something similar that Princeton does, they do like web Wednesdays. So it's kind of like, open for two hours, come talk to us for free. The more opportunities like social responsibility kind of business things that we do builds more of that sharing and people kind of sparking interest and go, oh, they really do know what they're talking about. Maybe I should look at that or maybe I should look at some of the contracts they have in place. I think that helps a lot. And kind of building on that, were there contracts with vendors in those edge IT groups before you created this campus one? Oh, I'm sure. We don't even get to see it and honestly, some people have what we call P cards and if it's low enough, they can just pay with a credit card and purchasing doesn't even have a list of what those are. So no idea whether you've been able to eliminate those and consolidate. We do know from purchasing that we were able to do consolidations on things we knew about absolutely. There's some edge cases where people are just paying with credit cards, Cornell credit cards that to be seen, I guess. It's so distributed, it's hard to put a number on it. Thanks. Yep. Hello. You mentioned briefly you're using a single sign on some of the sites. That's one of the things that I'm working on on a Drupal 7 project that's been lagging for an ungodly amount of time, but are you guys using LDAP back to directory? And if so, how does that work between Drupal 7 and Drupal 8? Cause I didn't see anything on eight about that. Maybe I just didn't see it. Sure. So I honestly haven't worked on Drupal 8 yet for the single sign on one of my colleagues has, but in Drupal 7 we're using simple SAML PHP and then simple SAML auth that does the initial authentication. We do use our AD, we have a replicated AD server and that's what we use to get groups and permit what we call permits, but AD groups. And I think there's an LDAP server module as well that that's what we're using to plug into that. For eight or for seven? This is all seven. I haven't worked in eight, I'm sorry. Do you know if anybody started doing any of that for eight? I can speak to that. Okay. So full disclosure, I have not built a single sign on with Drupal 8 yet but I've talked to people who have and there was actually yesterday but there was a really good session yesterday on how single sign on in Drupal 8 is actually a much cleaner process. It's way easier than you'd think in Drupal 7 because of the re-architecture with symphony. It's a cleanly sort of over-rideable system. So on the Drupal side in Drupal 8 I think it gets easier because there's sort of less hook overrides or form alters that you would need to do. On the actual integration side, I don't think it gets any less complex. And like we oftentimes when we do single sign on with universities it's some kind of SAML based, like that's the lingua franca of federated authentication and then behind that might be an LDAP system or something else. If you need to connect directly to the LDAP, that's also an option although that often is a little bit harder to wrangle with IT in terms of them opening up. They usually don't want to open LDAP up to the world or websites, but if you can, you can. Cool. Thanks. Appreciate it. Absolutely. Let me say we've got simple SAML and Shibla authentication working in Drupal 8. Go! Woo! All right. You know we're single in all the college of LAS. All right. Any more for any more? All right, well thank you. Okay. Don't want to rush. We've got plenty of time. So I'm curious if you can speak a little bit about custom sites that you guys end up developing and how you support them. I'm a developer at Princeton and we have cost recovery as well, but we have kind of our templated solution which is kind of centrally funded. As I'm sure you're aware of, you've talked with my colleagues about it, but the custom sites, the more that we add that we need to add because they're custom enough that they don't fit into our templated solution, they kind of become like a maintenance nightmare for us and the more that we add, the more time that we end up kind of sinking into them. So I don't know if you have some more challenges and maybe you can talk about that. The challenges between dealing with support and projects on a team is probably one of the biggest challenges we face. So more recently, and I think in talking with my peers at Wild Medicine, they might do this better than we do even. What we've tried to do is we bill everybody for support. So what ends up happening, which that part of the model works for us. So we know that we need to support them. We know Ryan can speak to patches and maintenance that side of support, but we also know that they might uncover a bug that no one ever found or there might be a module that an upgrade triggered something to break. So we bill them for all of that. And so we have a good model for doing that. Where it's disruptive is that times the 150 sites that we support, not all Drupal, but just tickets coming in, super disruptive for projects, super, super disruptive. So we've got people who are planned and scheduled on projects and all of a sudden they're off and they're doing support. So it's all billable work. So from the business side of the model, that part's fine. What I think Wild Medicine, if I understand it correctly, does better than us is they kind of do like a handoff from project to the support folks. We're trying to do that a little bit more right now. We tried to identify a pool of like three or four people and we said, okay, your role on this team is a very important role. You're gonna do the care and feeding and keep everything alive for us and keep this moving. And you're gonna tap the project people when you need to, when it's something so complex that you can't. It's kind of nice because it gave some folks on the team opportunity to grow, have ownership around something, but I think you need a lot of staff. Back when I had a little team, I have about a team of 20 right now. How could you split them up? Everybody did the same thing. So it was a little more challenging. We did work with vendors more back then, but now that we're a team of 20, we do have a little more flexibility to do that. Everybody that does projects, we reserve five hours a week, which I know is not much, for each one of those people to help on support. So that does kind of ebb and flow and it's baked in the schedule. So when any project comes in, there's already that five hours a week allocated for them to work on support so that we don't have this huge domino effect. So I'm from Wile? Yes. What we do at Wile is we have an ops team. That's their focus. They handle the JIRA tickets that come in on these special projects. Whatever new features might come in, they get the first crack at it. And as Shannon said, if they can't handle it, they hand it off to the dev team and then we'll take it off from there, but it's billable from that point. One thing that I would also add, just having seen, again, across many institutions, is separating out maintenance and support from sort of the must have patching and updating of modules from a security standpoint. And a lot of that is, while not fully automatable, there's investing in automation for that upfront, can really pay off if you're managing even just 10 or 20 sites. And then if those things, because if not the manual labor of that coming in, there's a monthly release or a bimonthly release for Drupal, there's a security release that's kind of urgent once a year at least, and that disruptive effect of having to just pitch in and kind of do the stevedore work of patching all the sites and getting them all out, that can really disrupt your schedule. So being able to reduce the manual burden of that upfront can then let you focus the scarcer human resources on when there's a problem with an update or when someone has a request and it's more like I need help fixing something or it's like a tiny mini feature request that comes in that you sort of have to handle as part of that. And then you kind of run it like, again, like an agency would, you have to figure out how to price that stuff. The other thing I have heard about people doing from some of the folks that we work with in the UC system is when they're a universal service but they also, they can't say no, but they can put a cost on bringing a site onto their platform. And they've built a general process where they'll do a quick evaluation of something before it comes in. And they'll just, not to be mean or anything, but they'll just try to say, well, look, I know you say this is a Drupal 7 site, but with the amount of core hacking that's been done here, this is almost like a custom application that we need to support. So it has a different price schedule that goes along with it. Or we've looked at this stuff and a lot of things are very out of date on this site. So we're happy to take it over and bring it up to speed. But it's gonna be a little mini project to bring it kind of like up to code before we can really take on the support. And that's a hard conversation to have because you're not supposed to say no to anybody. But I think when you're in a cost recovery model, figuring out a way that is genuine and legitimate and value added to have that like, what is the cost of what you're asking for? Because maybe it's easier for you to just migrate your contract into our cool like easy to support templates. And that's kind of, it kind of gets the customers on the other side of that to start to think that through that conversation on their own. I have two questions. One of them is for the new centralized news calendar. How do you, have you guys approach that? And if so, how do you plan to solve that? Whereby you have news from a central place that needs to go out or news coming from schools? How do you ingest that? The other one is for the IT hosting, how do you do the distrust? I'm from the University of Maryland College Park marketing department. Well, don't go too far. I might need some clarification, a couple questions. All right, so the how. So do you mean how are we planning it or the actual technical how and how we're gonna pull in news stories from like the Cornell Chronicle? So we do have a central calendar, central news that a lot of the schools are possible to submit news and also they ingest the news. So how do you resolve that? So ours will be very similar to that. And actually Nazrin luckily is here as one of our devs. You might wanna talk to her since I'm not a dev. Project management's more my background in business. But what we will have is we're gonna have a scenario where we're pulling from a central repository of events and news. Not everybody, it's kind of weird around campus wants to pull from the central repository of news. Some of them do, some of them don't. So what we plan to have in our distro is the ability to pull from both central news and central events. And then we also plan to have the ability for them to add locally on their site to it. And then also curate because there's a lot that comes in for central that they don't care. So the tagging's not always that great. But we plan to plan for both in ours. Does that answer your question? Yes it does. Okay, what was the second part? The second part is the distros. So if they choose or they're mandated to use the central IT, how do you give them a stack of the distribution that you guys are working on? Oh, how are we going to give it to them? Yes, or how do you plan on that? We're going to release it via just to get. Yeah, it's, we're not there yet, but the idea is to share it via Git so that we can just give them access to do it on their own without us if they don't need us. Thank you. When you give something over, what level do you let people customize it? And do you support it if they make changes and potentially sort of change it in ways you didn't intend or break it? So I think it's a little hard to hear you on the microphone. When we give it away, if they customize it and then come back for support? Yeah. Okay, so we're going to release the distro as a base to use for folks that really have no budget. They just need, we have a lot of folks on campus that actually have horrible, horrible websites. So this will help them immensely because at least it gets them off the ground. But we do, I think, communication is everything. So once we explain it to folks, we plan to say, you know, if you, kind of like Josh said, put a cost to everything. We plan to say, go ahead, take it. If you make a mess of it, or if you extend the heck of it and come back and ask us to support it, we're going to do, we do onboarding. So we're going to look at it. We're going to have devs like Nazrin and Ryan look across it and go, what did they do to it? How bad does it look? Can we fold it back in? If they took our distro and really didn't do anything different than we would have done to customize, we would just kind of take it back in and fold it in as support. But exactly what he just outlined, we'd put a really high-priced tag on it and have that conversation with them to help them understand why it's looking like it's like. And one additional thing that I've seen other folks do somewhat successfully and with like, I think it's a model that can work for the future is deciding whether you intend your distro to be customized or not is one thing. So like, is this a distro that is just going to be cookie cutter, nobody's going to change anything other than adding their own content? Or is it more of a quick start? You could use it, only it, but you might also add a content type or add a contrib module or let some of the open source action happen. That's really the question is, is your distro a starting point for an open source project or the endpoint of a SAS type solution? And if it's the, make sure that customers understand which it is, and if it is the starting point for an open source project, which I think a lot of universities want to do because that open source value of Drupal is something that all your clients want to tap in or not all of them, but many of your clients want to tap into too, try to give them guidelines like what you were just saying, the way we would customize it, if you can, the more you can have, tell them what they should be doing and be the experts in the room, the less likely they are to end up with a Franken site. We're just getting started with Drupal now, Drupal 8. Can we use Drupal 8 as our central events repository or should we use another system now, but we're wondering, okay, there's a time for us to make the switch? As a long time Drupal evangelist, I would say yes, yes you can. There are probably other systems you could use too, but being a central content repository of a structured data like events is something Drupal's pretty good at. You could probably find some good prior art in the community of people who've been down that road before. I doubt there's a turnkey solution, like oh just add, I don't think we're at the point where there's a module for that, but events are something Drupal's pretty good at tracking. All the data types you'd need to build out your own data model for what an event means for you is gonna be there, and then Drupal 8 has the best story ever to date with Drupal in terms of being a good web services platform, so being something that a lot of other clients are consuming is something that you're in a good position to do with Drupal 8. Go for it. So Nazar was just saying at Cornell they use a software called Localist as a central event hub, and then they consume, they have Drupal consuming localist API stuff to bring things in to individual sites. Right, so they'll be building the Drupal 8 sites with a client ready to go to consume those things. But again, I'll say you could get localist, but you could build it yourself in Drupal if you want to build it. It's all a question of how much dev-ing you want to do, you know? Yeah, I just gave it as an old question. Yeah, I think that, and that's very good because that's the specific question you asked. Is there other software that you also use? And yes, there is, and that's a good one. Hi, I'm Ben with Timing. Do you guys use a make file? How do you update your core and contrib modules? Do you ever do multi-site, share it with a shared database? Opened our eyes to it, and so we're really trying to institute that because they're just really cool and a really second question. Do you have multi-site? Oh, multi-site, yes. So we do have a few multi-sites. Some of them are splitting themselves out, so they won't be multi-sites anymore. But there are multi-site installs on campus, some fairly large ones that we used to support, but we don't anymore because they do have their own internal IT staff. Is there like support question around that? I forget. Yeah, right now we have mostly single-sites. And if we were better at coordinating the make files and figuring all that out, we could have been doing things a lot more efficiently sooner. You said you were doing like an open-source thing though, right? Is that something that you're thinking about doing in the future? Yes. You can share some code between websites? Yeah, I mean through the distrail, that's the plan. And with Pantheon, you can have your own upstream so we essentially update one thing and then push it down for those specific modules and for that core. If there's any additional modules added on, that's either the customer's responsibility or we'll do that for those that we support. Great, thank you. And one just note on the make file front. For Drupal 8 era, there's a gravitational shift towards using Composer as like the kind of manifest of record for Drupal sites because it gives you access not only to declare your dependencies for Drupal contrib stuff but also for any other PHP libraries you might have versus the Drupal 7 era Drushmake file which is really kind of a only scope to Drupal specific things. So if you like doing things of the make file style build which is super awesome and you're going to Drupal 8, you should really check out a Composer-based workflow. So I have a question. I walked in a bit after you had started. I'm from University of Chicago. We have, so what we did was we created a product line, Samir is back, call you Chicago Sites, and it's a multi-site, it got pretty popular. And we have hundreds of sites on it now. And it makes updating very difficult and it's kind of been like in the long run, now we're trying to, it's becoming a little negative. So we're trying to phase that out and just outsource it to somebody else for, to voices, I mean edu blocks to do that. And it seems like you guys are heading in a similar direction, creating that distribution. Are you planning on grouping those into smaller multi-sites or just one-off sites whoever wants it? Certainly I think we want to provide the distro for whoever wants to use it. I don't foresee us building any multi-sites for customers, I just don't think that's the way our team is going towards. Yeah. So we do have, we have worked with customers where we split their sites out for them so because they were running to similar problems, you know, someone changes something on one site and when you update it, it kind of blows things up. So I think the distro is gonna help with that to kind of manage that a little bit better. But most of our sites are now single sites, we're not doing a whole lot of multi-site. I know Josh has. Well, I'm just gonna, I'm gonna have to hold on. Sorry, I gotta put my vendor shirt back on. This is my jam. No, it's one of the main things that we've worked on a lot at Pantheon to try to solve this problem of, there are specific circumstances where multi-site can work, particularly if you're like really in that no customization SAS kind of model. It's still a challenge, but it can work. But on a campus, usually you need to allow some customization and some freedom and people want that open source value. So we have a model for deploying from a single get repository that is not actually running a particular site out to a lot of different sites on campus that can allow for customization to happen at the per site level, scaling to happen at the per site level, et cetera, and that you can manage those deployments much more effectively than you would with like managing a big multi-site installation. So it kind of allowing you to have the reuse and efficiency of a common code base but also retain the flexibility and creativity of giving people their own stuff without having the IT people in the middle of that lose their minds because of the chaos. And for the folks from Cornell, when these distributions go out, are these clients, do they have their own in-house Drupal people, are you also gonna be the same people customizing the sites for each one? Yes. Okay, they have their own. Cornell is, it could be all of that or any of it, really. We have really large IT groups on campus that can do all of their own stuff, essentially. They just come to us because they need some place to store their site. So that's when we say there's Pantheon or Zakhia or wherever, otherwise they're building it themselves. So yeah, they would be perfect if they wanna take our distro and the built theme and then kinda do whatever they want with it. Great, they have their own IT people, they can support it. Otherwise there are smaller groups that may have just a content manager or a front-end designer and then they just need to have a place to put content. So they can pull it down, this is our brand scheme or plan anyway, pull it down, we, Potts and Mike build it for them for a small fee and then they can kinda take it over and do the rest of it themselves. All of the above, really. It's quite a distributed and un-central campus. Okay. Yeah, I'm trying to find ways to restructure what we have at University of Chicago too because updating is a headache. So thanks. Sure, step right up. Not really a question. But somebody was asking about events earlier and how you might be able to manage events and one of the things we talked about in another session was how people actually doing that with Salesforce and sharing data between Salesforce and Drupal 7 at the time, but now they just released their, or they have a released candidate for a Drupal 8 module that does the same thing. So it's, you know, the possibilities are endless. Yeah, absolutely. Lots of ways to integrate things together. Did you have a question too? Hi, I'm curious to what is the deciding factor between choosing to put one client on Pantheon what put one another client on Acre? Am I answering that one? You know, initially when we talked about adding on another contracted vendor, that was probably the first question that came up. How are we gonna explain this to campus? It's actually not that hard for us though. So a couple of things. I think the easiest is what are you looking to do? Are you just bound and determined to have multi-site and that's all you wanna have, which we do have a couple customers on campus like that. And that's pretty much, you know, we do talk to them about Acre, but at the same time we also, for us it's about sharing information. So we try to say in our team this is how we're doing it. There's both vendors. This is how one does it. And then we share a bunch of articles, which I think Josh wrote some of them, just to help inform them a little bit around their choices. Outside of that, and it's kinda changed on how we talk about this, you know, price drives a lot of who somebody's gonna look at. So, you know, depending on which vendor has different tiered structures, sometimes that's what drives the conversation. So usually when we sit down with them we'll ask them about their budget and what are they looking to do. And before we go any further, not naming anything specifically, that really guides that discussion because sometimes somebody meets with us and they're like, I have this much money and I just need to host my site. Because it's, you know, it's just a one off site for them. It's different than a college site. The other thing that we help them look at and we try to be pretty fair on, you know, talking about strengths with each, is if somebody has emergency.cornell, we, you know, and they need, we don't even want them just looking at that middle tier of hosting with either provider. We really want them to buy into something higher. I think Ryan does a great job of explaining to them that, you know, if this happens you're gonna go down and here's where the strengths and both are each. And one question, and I would defer to Josh on this, is I kind of thought back in the day solar comes with Pantheon and does not or you have to pay for it with Aquia. I can't remember. It's something like that. But that was the other thing back a couple of years that used to come up a lot was the solar discussion between the two. Okay, cool, thanks. All right, well, I think we're at time and that was a great question and answer session. Thank you all for staying and for your presentation.