Because 'scheduling' in the real world (as opposed to 'scheduling as an operations research problem') is not as simple as you make it out to be. Every department has their own requirements, about being able to schedule labs, equipment, people, timetables at which specific security personnel is available, rush hour avoidance requirements, and dozens of other factors. It is not impossible to abstract all those away into an algorithm that can come up with a solution, but at that point, you basically need a programmer to make the schedule. Which is why consultants come in to customize the software to the specific situation, leading to a number of solution providers, which is the situation we're in now.
(grump mode on) I wish everybody who wants to hit submit on 'how hard can this be? I can do it over a weekend!' type of posts on HN would come off their high horse and apply Occam's Razor. If a problem exists, and probably thousands of people have already devoted substantial parts of their lives to it, how likely is it that some amateur on HN would come up with a better solution in 15 seconds after reading a cursory overview of it? Answer: negligibly likely. So what's the more likely explanation? That the reality is not as simple as the abstract overview makes one think. Which is exactly what is going on here.
There are few if any workable OS scheduling packages because it's boring and situation-specific. 'Scheduling' as an abstract problem is solved, all that is left are implementations, which are all site-specific. Exactly the type of situation in which OS has little chances of being a realistic solution.
I don't disagree that the problems are generally harder than one thinks at first blush. However, often many of the odd intricacies and rules people have around existing processes aren't necessary, and are there because they've always been there. The act of rebuilding a modern system can help root out some inefficiencies and streamline things.
Secondly, most places with computer programs should have enough competent people to choose from to collaborate on internal projects like this to avoid the need for everything to be an outside consultant or purchase. If a small team of graduate students can't handle some of these problems, I would consider that an indication that the programs aren't doing a good enough job. I understand not every "computer science" person is a naturally good programmer - there's a distinction, etc. But there still seems to be a waste of available talent on-campus that could be tapped for some problems.
And my particular favourite: scheduling one off exam slots in medium sized rooms at unusual times of year (UK, further education, modular basic qualifications, externally marked exams). Last time, they put an exam in the room next to a music practice room...
Ah yes, spatial relationships between resources, the bane of every class scheduler across the world. The complexity of relationships between resources can explode so quickly to a degree that it becomes impossible to foresee every situation. So the software has two options: build in a Turing complete language to list this sort of dependencies (too hard to use for users), or allow large amounts of manual 'exclusion lists' for special situations. After a few years, those lists get so large that they start to contain internal conflicts. Then there are a few years of screwed up exam plannings, people get yelled at, new system gets implemented, and the whole circle starts again.
(grump mode on) I wish everybody who wants to hit submit on 'how hard can this be? I can do it over a weekend!' type of posts on HN would come off their high horse and apply Occam's Razor. If a problem exists, and probably thousands of people have already devoted substantial parts of their lives to it, how likely is it that some amateur on HN would come up with a better solution in 15 seconds after reading a cursory overview of it? Answer: negligibly likely. So what's the more likely explanation? That the reality is not as simple as the abstract overview makes one think. Which is exactly what is going on here.
There are few if any workable OS scheduling packages because it's boring and situation-specific. 'Scheduling' as an abstract problem is solved, all that is left are implementations, which are all site-specific. Exactly the type of situation in which OS has little chances of being a realistic solution.