There has recently been an interesting conversation on the Bricolage mailing list in reaction to a review posted here. I like reading these threads as they progress from indignant rejection of criticism (some major inaccuracies like that the project is dead and also some constructive feedback) to introspection and the acceptance of new ideas and input. On the point of the project being dead, the mailing list started to think about ways to keep the website more up to date and be more vocal about new developments - not everyone, including some software reviewers it seems, reads the mailing list. One of the very valid points was how difficult Bricolage is to install. Having installed it several times on various platforms as well as many other open source CMS, I can confidently say that Bricolage is one of the hardest installs that I know of. I remember Midgard also being pretty bad but that was a long time ago and they may have improved. The general consensus within the list was that installing Bricolage is pretty much a nightmare unless you are running Debian.
While reading the thread, I was thinking about how in the not so long ago past, no enterprise software installation was a trivial task. Installing these systems required a significant amount of time by even experienced engineers. When I worked in professional services for a CMS vendor, our teams were always deployed after an installation engineer (who did nothing but product installations) took three days to install the product. And that is after the customer could demonstrate a fully operational database and J2EE certified application server. Perhaps we shouldn't abandon this expectation altogether.
Many of the open source CMS that I track have packaged installers or self contained bundles that you can just download and run. Open source applications should definitely have this capability. Otherwise, the primary advantages of the open source model (cheap distribution and accessibility for experimentation) are lost. It doesn't take long for a user to give up on an application if he is presented with roadblocks before even experiencing the features of the software. Many products take this accessibility one step further by setting up hosted installations so that business users can try out the software without even installing it.
Of course, you should never use these installations in a production environment but they are good for trying out the software and, perhaps, for a development environment. If you want to run a production system, you need to really understand the application, its vulnerabilities and how it behaves. ArjÃ© Cahn, from Hippo CMS has a very good blog post reminding us about how important it is to pay attention to software configuration even for software, like Apache, that has a reputation for being secure. In the JBoss administrators class, you learn that JBoss "out of the tarball" is totally insecure and can be shut down or compromized by anyone with network access to the box. For tips on securing your JBoss installation, go here. Shipping JBoss this way makes a lot of sense. With all the security turned on, your average developer is going to constantly run into obstacles and not know whether it is his code or something else. It is the system administrators job to lock it down... and then break application ;). TYPO3 does a nice job of keeping vulnerability warnings in your face until you change the password from the default and delete the setup files. Some products like eZ publish allow you register your site and have services for monitoring your application. This could be a good way to provide a vulnerability report service.
I think the message for all enterprise software should be to keep the hurdle to experimentation as low as possible but be very clear about what it takes to establish a robust, secure production environment.