Comment Don't forget inherent qualities of universities (Score 1) 149
There are many aspects to an ICT policy. I'll just address a few points related to procurement versus in-house development, which is one key issue. Universities tend to draw tech advice and management from people who overapply lessons from the corporate world and forget things that are unique to universities. For example:
(1) In my university administrators have consistently bought expensive proprietary tools from companies that do not specialize in academic software, e.g. modifying e-commerce tools to be student course registration and tuition systems. This can lead to mismatches in the user experience - the student's course list becomes a "shopping cart" with a "checkout", and functions that are necessary on a local level either don't get implemented or have to wait in a long list of changes that are expensively requested from the vendor, such as accommodations to allow for flexible credits when that wasn't built into the system or didn't follow readily from the original software model.
(2) Part of the reason for going with off-the-shelf solutions that are poor matches for local needs is the bizarre and usually mistaken belief that there is insufficient in-house talent to get the job done. In few places is this less true than at a university with computer science students, who will often hack cheaply and or even for free and have created some truly terrific tools that blow away expensive proprietary ones. IT personnel are also often more available to hack at a university than elsewhere. University IT departments often attract good programmers who are somewhat underemployed because they like working in a university. In most cases, a tailored solution, open source generally, will be cheaper to produce and certainly to maintain in a university than it will be to buy software from a vendor, even if the vendor specializes in university software. This is less true as you move toward very specialized types of software such as graphical modeling tools, but universities often spend huge amounts of money on vendors to buy stuff with really simple interfaces that could have been developed locally or in consortium with other universities.
(3) Another mistake is letting software drive policy. Software maker says "from now on, courses can't meet at nonstandard times" or "instructors can't change the grading basis", etc., and rules that used to be determined by academic committees get made de facto through programming choices that no one at the university had a say in. Another argument against outside vendors and in favor of in-house development when the software is not terribly complicated.
(4) In some universities the concept of open source goes ideologically against what the powers that be want to promote, e.g. students graduating and forming companies based on proprietary software, or not pissing off donors from such companies. It's not clear this can be called a mistake in the context of the school's overall economic model, but it is a mistake to forget this bias when explaining why a school's IT policy does not favor free/open source software.
(1) In my university administrators have consistently bought expensive proprietary tools from companies that do not specialize in academic software, e.g. modifying e-commerce tools to be student course registration and tuition systems. This can lead to mismatches in the user experience - the student's course list becomes a "shopping cart" with a "checkout", and functions that are necessary on a local level either don't get implemented or have to wait in a long list of changes that are expensively requested from the vendor, such as accommodations to allow for flexible credits when that wasn't built into the system or didn't follow readily from the original software model.
(2) Part of the reason for going with off-the-shelf solutions that are poor matches for local needs is the bizarre and usually mistaken belief that there is insufficient in-house talent to get the job done. In few places is this less true than at a university with computer science students, who will often hack cheaply and or even for free and have created some truly terrific tools that blow away expensive proprietary ones. IT personnel are also often more available to hack at a university than elsewhere. University IT departments often attract good programmers who are somewhat underemployed because they like working in a university. In most cases, a tailored solution, open source generally, will be cheaper to produce and certainly to maintain in a university than it will be to buy software from a vendor, even if the vendor specializes in university software. This is less true as you move toward very specialized types of software such as graphical modeling tools, but universities often spend huge amounts of money on vendors to buy stuff with really simple interfaces that could have been developed locally or in consortium with other universities.
(3) Another mistake is letting software drive policy. Software maker says "from now on, courses can't meet at nonstandard times" or "instructors can't change the grading basis", etc., and rules that used to be determined by academic committees get made de facto through programming choices that no one at the university had a say in. Another argument against outside vendors and in favor of in-house development when the software is not terribly complicated.
(4) In some universities the concept of open source goes ideologically against what the powers that be want to promote, e.g. students graduating and forming companies based on proprietary software, or not pissing off donors from such companies. It's not clear this can be called a mistake in the context of the school's overall economic model, but it is a mistake to forget this bias when explaining why a school's IT policy does not favor free/open source software.
