The University of Oregon’s developer community is interesting. I’d say unique, but from speaking to developers at other universities, I’m under the impression that our situation is fairly common at large institutions. With 25,000-ish students and hundreds of schools and departments supporting them, there comes a few thousand websites to provide information about enrollment, financial aid, majors, classes, housing, dining, activities, events, and on and on and on. Typically, developers are hired in far-fetched corners of the institution and charged with one area’s concerns. Thusly, to support a thousand sites, we wind up with a few hundred developers, ranging from $10/hr students to $100k/year professionals supporting this odd, cobbled-together infrastructure.
I’ve written about this problem elsewhere, and rather than re-hashing it I’d like to look at some interesting ideas that come up as we head down the road to recovery. Eventually, all these programmers start talking to each other and realize that they’re all working on essentially the same problem. As we begin to collaborate organically, realizing that we have common problems and coming together to find common solutions, we start to emulate open source software communities, and we run into one of the biggest problems in OSS: encouraging contribution and eliminating barriers to first commit.