nwhittier

A lot of the passion in open source comes out of the building, editing, and nurturing of the product itself. As you mention, when the curriculum mandates task A be completed between dates 1 and 2, and task B be completed between dates 2 and 3, there is very little incentive to have lasting interest in a particular task. Why should a student bother to invest passionately in a project when it has no inherent longevity?

It certainly is not easy to force alternative curriculum options or to simply allow students to work on projects for which they hold the most interest (passion). But I think it is possible to get students to work on longer term, multi-faceted projects that could allow iterative work pertaining to each lesson as it comes. This would cater to your release early, release often idea; while also (I think) allowing for a more appropriate grading metric. This turns grading into a more cumulative effort on the part of the students. These lessons could also be a little more amorphous in terms of scheduling, because it may be worthwhile for a student to return to their previous implementation in order to make the next section work better. It also allows student to focus more on the lessons that inspire them more, and pay less attention to sections that are not of interest, as the cumulative nature would effectively reduce the grading weight of each individual lesson.

I am not certain what the most effective implementation would be, but I feel we need to make learning feel a lot more like a series of related challenges or even a game. These types of longer term projects work well for group activities, and also enhance the cumulative nature of education by highlighting the importance of iteration, updating existing work, and learning from mistakes. As a bonus, I think this also makes education a better means of training for life, which is rarely assessed in such a compartmentalized way.

Ken made a good point above, highlighting that WP is probably a target of attack as a result of its market share.

However, I think it's also important to further distinguish the technical ramifications of this obscurity, since anyone new to Plone, or CMS in general, may not know how drastically distinct the above four systems actually are.

Drupal, Joomla, and Wordpress are vastly different systems to an end user, but to a developer who is initially configuring a system, they all work relatively well behind a standard (read: inexpensive) server stack consisting of Apache 2 Http server, PHP, MySQL - and probably on Linux. Plone sits atop Zope and relies on Python.

To enhance the security through obscurity argument a little, review <a href="http://trends.builtwith.com/">builtWith trends</a> and <a href="http://w3techs.com/">w3 tech surveys</a>, where you see that Apache and PHP hold substantial market share, and within that share, Drupal/Joomla/Wordpress make up a substantial portion of the sites. Also notice that Python/Zope/Plone make no appearance.

This is not to imply anything about Plone/Zope as a solution. Rather, I mean highlight that one can not consider the security table as the sole decision maker, and that anyone unfamiliar with these systems must consider the less apparent cost distinctions that result from the different technologies and requirements.

The Zope/Plone stack is quality software, but it costs more to run and develop. The following is debatable, but I would also propose that it is much cheaper and easier to find talented PHP devs interested in supporting gov't projects, as compared to Python devs. However, the TCO investigation is a post of its own, with more to consider than I will investigate here.

So anyone who finds themselves here to investigate CMS and security should know that Plone is worth investigation, but that the mentioned systems for comparison are quite distinct beneath the surface - and these distinctions will have substantial ramifications on the project.