This semester I’m teaching a graduate course with students from both our Quad Cities and Macomb campuses. As I’ve done many times, I’m using a WordPress weblog to extend the conversations in the classroom. For my other two classes, I’m also using web pages to deliver handouts &c. On the first day of classes, I had to explain why I don’t use WIU’s WebCT installation, and why students would be using an off-campus host. A student who’d taken classes with me before quipped, “It’s because you’re an open source hippy, and Western doesn’t allow that on campus!” Well, the first part of that is true: though I’m not a hippy, I use open source software as much as I can.
Western is fairly open to open source. I say “fairly” because while I can think of several cases where open source software is readily available and used on campus, I can also think of several examples of software procurement where open source was basically eliminated from day one. Overall, I’d say the climate could be better. Folks like me who want to install and support their own software on WIU servers aren’t prevented from doing so by policy. But we do have to contend with a very outdated web server. That’s what drives me to wrecking.org for my WordPress installs; it’s much easier to keep the software up to date there.
Having said that, Clancy Ratliff reminded that many people aren’t so lucky, when she wrote to ask about my use of open source. It’s not unusual for IT staff to object to open source software because of security, privacy, problems obtaining support, a lack of standardization, or all of the above–whether or not such problems exist. So, as Clancy asked:
How should faculty respond when university IT staff members express suspicions about open source software, and refuse to install it and/or support it?
What exactly are they afraid of?
I think Clancy’s second question points to the answer for the first. First and foremost, faculty need to fully understand the grounds for any reluctance to install software. Many (most!) IT staff work with limited resources and have epic demands on their time. They’re not really afraid of anything; rather, they simply don’t need more to deal with. For example, I used to get a single course release (from a standard 3/3 load) in exchange for service as department technology coordinator. That was about half what it should have been. Hell, maybe a third. So I made decisions based on the amount of time involved, refusing most time-intensive projects out of hand. It didn’t really matter what the project was; if it was labor intensive, the answer had to be “No.”
So let’s back up a step: faculty should think carefully about the way they make requests. Obviously, emailing the helpdesk, “Plz install OpenOffice in r computer labs kthxbai” isn’t going to cut it. But it’s often equally ineffective to drop a two- or three-page request email into a system administrator’s inbox with cc: to the department chair. Rather than ask that something be installed, ask to meet to discuss possibilities–and don’t invite the chair. A little dogfooding really helps: when students ask for deadline extensions, alternative assignments, or things which make unexpected demands on our time, how do we react? More favorably, I think, when students make open-ended requests which invite us to help shape them.
I suggest this framework:
- An initial meeting to discuss the project in general terms;
- Research which answers questions about the scope of the installation;
- A proposal which shapes the request as a project with desired outcomes, a schedule, and a primary contact.
Imagining the installation and use as a project shouldn’t unnecessarily complicate things. Rather, a project framework can clarify what’s expected of all parties, for how long, and for what purposes. Above all, that documentation makes it clear faculty will communicate with IT staff about the project, and not expect them to go it alone. And if it turns out that internal or external funding will be needed, turning an initial request into a grant proposal won’t be difficult.
Research should address the following:
- What, specifically, are the software and hardware demands of the installation?
- What support needs will be generated? Who will need help? When? With what expected turnaround time? Who can provide help? When? At what cost?
- Consider support alternatives: should help requests be diverted to faculty, TAs, or others? If so, will additional funding be necessary?
- Clarify the time frame: is the product to be installed and maintained for a single semester? For an academic year? Forever?
- Why is the software needed? For a single class? Multiple classes? An entire program?
- Is similar software is already on campus–maybe not in the building, or even close by, or even on this campus? Is that alternative acceptable? Why or why not?
- Will the software create unnecessary risks to computer security or stability?
Security is last here. It’s first for many. As Clancy continued:
Are they afraid that, say, OpenOffice contains spyware that could compromise the privacy of student records? That hackers can, via the open source application, send worms and such into the university network? Other stuff too?
What’s your advice for faculty who want to get open source software installed in university computer labs but have to deal with this obstacle? Are there sources in particular that you recommend, sources that offer evidence that open source software is generally secure?
I’ve had proposals for installing software shot down because of security risks, real and otherwise. I’ve refused them myself. The risks are real. However, for me, arguments which compare the relative security of open source and proprietary software miss the point completely. All computing is risky. Rather, I suggest that faculty research the security and securability of specific software involved. Have project developers, and third parties, audited the codebase in the past? What mechanisms for reporting bugs exist? How do developers typically respond to bug reports? How often is the software updated? How are updates installed? Can the software be installed on a “sandbox” server, or access-controlled in some way?
Again, asking IT staff what questions they have is a good idea–not in a predatory manner, but with forward thinking in mind. With answers to these questions, staff can better understand the risks involved with a particular software package, and the measures necessary to minimize the chances that risk will develop into actual problems. On the other hand, faculty can point out refusals to install “insecure” software which are unfounded.
Finally, faculty should help establish a means for evaluation of the use of the software over time. Two related parts:
- Is the software actually being used by the expected population? If not, it should be discontinued, and the reasons for non-adoption investigated. On the other hand, if adoption is enthusiastic, will additional resources be needed? Might others be interested in helping scale up the installation? In that case, evaluation shows good reason for continuing maintenance and upgrade cycles.
- I wish we (big we: higher education, and little we: geeks who teach writing) had more data on the comparative quality of the software we use to do our jobs. I’ve used WordPress for discussions for a long time, and had varying reactions to it from students. But I’ve never heard a student praise WebCT. As higher education gets more and more data-centric, we need ways to make the arguments I outline here in terms which administrators will be willing to engage.
I’m interested to hear what others think: how would you answer Clancy’s questions? Why? What problems do my answers raise, or ignore? What have you done to get the software you would like to have in your classrooms, on your campuses?
