The balance of power changed drastically over the course of the 1990s, as the cable industry consolidated into a handful of very large companies and enormous amounts of investment were made in fiber to support two-way services.
That's a really good point. One of the problems with doing real-world examples in a general introductory college math class (ie, calculus, probability and statistics, >25 students) is that many of the subjects one might use require quite a bit of basic knowledge about the field that the example is drawn from. So we end up with the same tired old problems based on experiences that a majority of the students will have a grasp on.
The problem is that most sites for the first two categories are either already taken or politically difficult...
The map on page 25 of
this NREL document
does a good job of showing potential conventional hydropower by state,
separated by already developed, excluded (your political difficulties, mostly), and undeveloped.
There are significant amounts of undeveloped hydro, mostly in the West.
Electricity is, and is likely to remain, a regional thing. The US doesn't have a single power grid; it has three -- Eastern, Western, and Texas -- that are almost completely independent of one another. The Western area is particularly rich in a variety of renewable sources, many located relatively close to the population/demand centers. The Texas area has a more limited set of resources available. The Eastern, particularly compared to its total population and demand, is poor in renewables. In addition, the Eastern's best renewable resources are quite far from the big population centers.
This is what I was thinking as well; just get together with peers in a similar situation, and 'Kickstart' an OSS version of the program, thus forever freeing yourselves from the shackles of proprietary software.
Based on some limited experience (largely post-mortems on failed medical software deliveries), and assuming that any sort of patient records are going into the system, I'm comfortable guessing that the "kickstart" cost will run to tens of millions of dollars. The big companies that play in this specialized field have entire groups dedicated to tracking the changes in federal and state government requirements. The people who use the software are going to insist on support contracts to keep the software in compliance as those changes appear.
If they can't find it, I'm quite sure some coders would be willing to write some for substantially less than than the $10,000 required for switching to yet another version of Windows that will be out-of-date in a year or two.
Are those coders working for a company that understands all of the HIPAA requirements
that the code has to meet?
Are they prepared to certify that the code does in fact meet those requirements?
Are they working for a company that can afford the lawsuit if
HIPAA privacy requirements are violated, even if the software is not at fault
(and trust me, the company that provided the software will be included in the group being sued).
Do those coders have experience in providing the government mandated audit hooks
required if Medicare or Medicaid patients are treated?
In the last case,
it's not enough to provide some sort of audit hooks;
you have to meet the very specific interfaces and data models specified by the government.
Building software for medical care providers has become a nightmare. In some parts of the industry, there are only a handful (as in literally four or five) companies that are eligible to bid for new software system contracts.
One of the other advantages for the troff approach at that time was version control -- the documentation folks could use the same system that the coders used.