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.

Or IBM's APL interpreters from the end of the same decade. Talented programmers have known what a debugging environment should provide for more than 40 years. Interpreted languages got there first, for all the obvious reasons. Same stuff just keeps getting reinvented for different languages and systems. That doesn't mean the new stuff isn't good, it just means it's not really new.

Then it's up to the physicists and mechanical engineers: without some cheap and easy method to LEO, we're not getting off the planet in numbers and equipment sufficient to survive out there. Say, controlled gravity.

Not in terms of learning curve for writers who are used to Windows or Mac.

A few years ago I looked reasonably hard for the study, with no luck. May well be that the report never saw the light of day outside of the Labs -- lots of stuff got written up and distributed internally that never got published outside. I wouldn't be surprised by studies that found higher percentages. IIRC, the test subjects at the Labs were people doing technical documentation who knew that how they were rated when it came around to performance review included a "how much text did you process?" component.

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.

Me, I'm an old geek (working on ancient) and have one of those 5-digit numbers. I learned text formatting on n/troff— and the preprocessors tbl, pic, and eqn— at Bell Labs in the late 1970s. Not up to TeX's standards for typesetting quality, but simpler to pick up quickly and ran in remarkably little memory. I still use groff and tbl to produce quick-and-dirty tables for throw-away documents because the defaults produce reasonably attractive results. There may be people who can do nice tight tables with text and numbers using Word, but I'm not one of them.

Fun to see just how many of the people that jump on a discussion like this one have 4- and 5-digit user numbers :^)

...no distractions while edition (MS GUIs suck)...

At some point there was an internal study at Bell Labs after WYSIWYG word processors were beginning to be available that found most people spent 20% of their time futzing with how the document looked instead of writing. Most of that time was wasted because subsequent changes were going to wipe out whatever the little tweaks had been intended to accomplish.

Interesting that today you can buy programs whose primary purpose is to blank all of your display except for a green-on-black mono-spaced text window. Sold as an aid for professional writers who need to pound out umpteen pages of text per day, so need to avoid interruptions and distractions while composing.

I can't really explain it other than to say "you get used to it." After a while, the markup becomes transparent...

Just like learning any other language, I suppose. Years ago I had a guy working for me who could do it with troff's pic preprocessor. He could "draw" lovely semi-technical diagrams of various sorts writing text in an editor in one window with a second window set up to render it when he clicked the mouse there. It didn't hurt that he had accumulated a whole library of code for drawing various shapes that he used frequently.

Current hardware is amazing, but we've become so inured to bad software (chose any definition of "bad" you like, slow, bloated, buggy, insecure, incompatible, leaky...except perhaps "ugly" which we're doing Ok on) that so far no one else has even mentioned it. Until we start addressing that, better hardware will just lower the bar on the next round of software.

That is a way around the "problem" for the publishers.

Particularly when they convince the schools to include the e-book license fee as part of the cost of the class. "We don't care where you download the copy, we get paid regardless."

You're incorrect. Wow, that was easy.

Oh, I noticed every word in your post. Saying that not all Americans are part of a tyrannical mob doesn't preclude the bigotry I pointed out. You conveniently ignore the other countries' mobs, singling out Americans as if it they're especially tyrannical, as I said. Somehow in your undeserved condescesion you missed all those words in my post, its only point.

And pointing out your fallacy and your bigotry it comes from isn't an "attack", it's the mildest reprimand of something I don't like (because it's dislikable). Then there's how you say one person criticizing the logic and spirit of your post is "tyrannical". You should look that word up. Probably look up most of them. Don't bother getting back to me until you can speak English, or some other language Google translates adequately.