Working at a large, distributed institution like a public university is interesting. The University of Oregon is home to some 20,000+ undergraduate students, not to mention grad students, faculty, staff, and so on. As you might imagine, an institution this large has a similarly large web presence, with literally thousands of pages covering colleges, departments, classes, programs, organizations, etc.
For example: at Oregon, we have a few key pages: The homepage, pages for the individual colleges (Arts and Sciences, Architecture, Law, Business, etc.), athletics, and so on. However, this is only the tip of the iceberg. Departments, professors, student groups, classes, campus initiatives, and on and on and on all need sites. I’ve un-scientifically estimated the total number of sites deployed at Oregon at a (very) rough ballpark of ten thousand.
To create this mammoth web presence, we’ve taken what seems to be a typical approach for universities: hire dozens of web developers and hope everything turns out ok. Enrollment hires a developer to make enrollment sites, the business college hires someone to make their site, some student makes the computer science page, some contractor makes the site for the music school, and the physics department is still sporting that site a professor made back in the early 90’s. Universities are full of smart people and were early adopters of the internet, so back when this whole web thing was getting started and the concept of an IT department hadn’t really been invented yet, it made sense to grab the nearest nerd and put them to work. Today, this model’s still around, but it doesn’t make sense any more.
Turns out, if you hire 15 developers to make 15 websites, you’ll probably get 15 different combinations of languages, libraries, and frameworks. If you hire some combination of students, faculty, staff, and contractors to make thousands of sites, you wind up with an ummaintainable pile of websites, and you’re in trouble when someone quits and the next poor stiff has to come in and make sense of it all.
From talking to colleagues at my institution and others, it’s apparent that this problem isn’t unique to our university. The way we arrive at this mess is somewhat understandable: From an individual developer’s point of view, they’ve been hired to make one or two websites, so it’s somewhat reasonable for them to take that problem at face value and make decisions about technologies in a vacuum. Yet while this seems reasonable on an individual level, we can see the disastrous results of failing to appreciate the actual scope of the problem. To succeed, you have to see the bigger picture and accept the scope of the task at hand.
If your institution needs to maintain 10,000 websites, you personally might only need to build one or two websites, but you need to consider your own responsibility in the context of those other 9,998 websites your colleagues are working on. It seems like a daunting idea, but there’s hope.
In my mind, the solution lies in open source, and specifically in large institutions becoming open source communities. Lacking a strong central authority to give direction, individual developers with individual concerns have to begin discussing common problems and seeking common solutions out of necessity. Our sites should all look roughly the same, so we should be sharing theme assets. Our sites all need to interface with the same systems for student data, learning management, and scheduling, so we should be sharing knowledge about those systems and code to interface with them.
There can be a number of barriers to adoption of this model, as with any open source project, and converting your peers into contributors isn’t easy. That being said, the pain of a culture shift is worthwhile if your current culture isn’t working. Adopting a culture of transparency and openness makes everyone better off, makes the institution itself more effective and consistent, and might just let you sleep better at night knowing you’re not the only person on earth that knows how your technology works.