Thanks Cliff and Corey for the comments. Here's some additional perspective:
Separating curriculum materials into Passive and Active is an attempt to help instructors ensure that, for each Module and associated set of Learning Objectives, students have an adequate chance to practice the concepts, and that there is some balance between the two kinds of materials. Over time, I have found that I will consciously prune the initial set of Readings (for example), in order to make sure that students have enough time for the active materials. Or I will realize I need some additional Active assignments.
There is more than just a "tool requirement" to get (for example) multiple views. When you create Morea sites, each file has metadata indicating that its contents represents a Module, Objective, Reading, Experience, or Assessment. This is key: Morea is opinionated, and you have to buy-in to its representational system. The "tool requirement" also means that it's trivial to separate content from presentation. This was a big selling point for one of the professors using the system---he was happy to represent his courses using Morea because he figured if he didn't like the tool, he could build his own replacement. (And, in fact, he built his own command line tool (
http://morea-framework.github.io/morea-lintui/) to facilitate his own site processing requirements.) I am undoubtably biased, but I don't see how anyone can make significant improvements to curriculum organization without first deciding on a set of representational primitives (i.e. M,O,R,E,A) and then building the curriculum contents within that representation. MOREA might not be the right or best set of primitives for this group, but it's worked well for me for quite a few years now.
Sharing reference solutions in Morea is done in the following way. First, the GitHub repo hosting the site must be made private. That means that access to the source files can be controlled by the instructor. Second, within the source branch of the repo, any directories named "_ignore" are not processed when creating the publicly available, HTML version of the site. So, let's say you have a module named "Foo" whose source curriculum materials are in a directory called "foo/". You can create a "foo/_ignore" directory, put your reference solutions in there, and then they can be managed as part of that module without being accessible from the web.
Regarding having answers published in the wild: I don't have a big problem with this issue, for several reasons. First, for most of my course, I require students to build the solutions to problems as part of a private GitHub repo, which means (a) access to it during the course is restricted, and (b) commit timestamps and contents can be used to figure out when work was done. Second, I don't reuse certain important assignments from semester to semester, so even if a student has access to old problems, they are not different in character from the homework assignments they already have access to. Third, I actually like having related problems available in the wild for my course, because I think it helps the learning process. YMMV.
Finally, my "theories" about barriers to Morea adoption. I've had lots of ideas about this over the years, but here are two to get you started:
(1) Using Morea requires elementary knowledge of Git, GitHub, Markdown, and the command line. Gaining this knowledge might be too taxing for some faculty. It would be straightforward to significantly reduce this issue by creating a desktop app (say, in Electron) that removes all the Git/GitHub and command line knowledge requirements, but I have zero motivation to build it.
(2) Using MOREA means thinking more deeply about the pedagogy than just picking a textbook, downloading the PPT from the publisher's site, and assigning homework problems from the back of each chapter. For at least some universities, the incentive structure is designed such that all time spent on undergraduate teaching is non-optimal.
Philip