When I wanted to make the "guitar switch" in http://worrydream.com/ExplorableExplanations/ I took a look at the Web Audio API and recoiled in horror at the complexity.  I had no idea what they were talking about, and I've implemented all that stuff myself.  Fortunately, I also read that the API (at the time) wasn't well supported and basically didn't work, so I did it in twenty lines of Flash.

Bedrock abstractions (such as "the only way to generate sound on the web") shouldn't have a grain.  The libraries and languages that others build on top of them should have grains.

There's a bit in one of Stroustrup's books, where he mentions that a language designer constantly hears "This is a really common need -- it should go in the standard library", and he responds with, "No, it should go in some library.  But not necessarily the standard library."

I'm perversely fond of how low-level the Dead Fish and Drawing Dynamic Visualizations systems are -- they're kind of direct-manipulation geometric assembly languages.  There's something about that purity that helps you understand the essence of the new concept, without being obscured by compiler or IDE "helpfulness".

Yeah, you don't really want "open source" so much as "explorable source".  You need to be able to descend and actually understand it.

I made some mockups for Alan's STEPS project, to try to suggest that the source code of the operating system should feel like an interactive book (with chapters, sections, etc. corresponding to functional components) where there's a high-level description/depiction of every module, and you can go deeper as needed, and this readable explorable description is the running source code of the system.