Enter Content Here

Following in the vein of Tony Byrne's 10 Steps to a Successful Vendor Demo and my post on how to sit through one , here is a link to Joel Spolsky's How to Demo Software article. Besides being an entertaining read (as all Joel's posts are), I think this article re-enforces the importance of the performance and other production values to a vendor demo.

This morning there was an announcement on the Magnolia user mailing list that the first release candidate (RC1) of version 3.5 is now available for download. If you were waiting for version 3.1, don't worry, you didn't miss it. It is the same release. Still, this is a pretty big release. Some of the more notable features is better internationalization support. It used to be that localized sites needed to be managed more or less independently with no real relationships between different translations of the same asset. The new version provides better support for 1:1 localization schemes. Future releases and add-on modules will provide more functionality in this area. The new version has also been re-factored to be easier to customize. For example, many of the configurations have been transformed into beans that can be overridden and extended. There is also better support for filters. Security has also been enhanced with URL level access control (in addition to content level access control).

The Enterprise Edition will be released after the Community Edition is final and stabilized. If you are using Magnolia Community Edition, you might want to download it and give it a try - especially if you have built modules. The Magnolia team has tried to support backward compatibility for 3.0 modules but you never know. Now would be a good time to tell them if there is a problem.

At the cmf2007 conference last week, there were some great sessions and conversations about intranets including James Robertson's presentation of the 2007 Intranet Innovation Awards . There were also many interesting discussions about Facebook inspired by BJ Fogg's insightful keynote on persuasive technology (this guy knows his Facebook - he teaches a college course on it at Stanford). The two topics merged with the provocative assertion: "Facebook will be your next intranet." The idea has been clattering around in my head all week and then I read this news that Serena is starting to use Facebook as their Intranet on Toby Ward's Intranet Blog. I am sure that Toby's article was what got the whole conversation going but I didn't know it at the time. Apparently, the CEO of Serena is a huge Facebook user and has designated Friday as a day when employees should spend an hour exploring and interacting on Facebook.

What fascinates me about this idea is that most Intranets fail as social collaboration tools because they cannot capture the energy and passion that seems to form spontaneously on the web. At least that is my theory. And my theory goes on to assert that people do not invest their personal energy on their corporate intranet because they don't own it. While people do not own Facebook, there is a tacit agreement that a user's Facebook profile belongs to the user. The user can always access it and edit it and he is free to do with it what he wants. A corporate intranet cannot provide this assurance. When the employee leaves the company all the creativity, personality and knowledge invested in the corporate intranet are lost to him. A user has a right to feel like he owns his personality, friendships and ideas.

Because people are not owned by their employers, they interact in a community that transcends corporate boundaries. This is why internal instant message system are never as popular as AIM, YIM, and MSN Messenger. This is also why email crushed those internal messaging systems that companies used to use. You need to communicate (professionally and socially) with people outside of the firewall as much as you do inside the firewall. If your network is entirely contained by your company. Stop reading this blog post immediately and go out and meet some people.

Internal communities of practice fail because the population is not large enough to support them. If you ever took an ecology course, this is similar to Island Biogeography. Just as species cannot survive in small, isolated pockets, neither than communities of interest. You need a population that is big enough to allow healthy turnover and new ideas. If you are interested in a topic, you would do better to join a large open community than to try to start one with the three people in your company that share your interest. It used to be that the physical proximity provided by and office made intra-office communities more viable. Now, with the Internet, location is less of an issue. Being co-workers is an arbitrary requirement to community building that often stands in the way.

So, back to Facebook. The biggest argument against Facebook as the corporate intranet is information security. Much of the information that employees work with needs to stay within the company. Furthermore, there is a fear that allowing employees to be visible makes them vulnerable to being stolen by other companies. If your company is such a bad place to work that the only thing retaining employees is that no one knows about them to hire them away, you have bigger problems than your Intranet. Ideally, employees from other companies would see your employees on Facebook and all the fun they are having and want to come and work for you. Even if they do not come to work for you, they might be inspired to provide feedback or information that will be of some value.

Facebook would be a poor place for people to collaborate on company projects and other strategic stuff. However, how much of this information actually needs to be private? Does a company holiday calendar need to be private? Probably not. An interesting exercise would be to go though your Intranet and identify all the content that could be out in the open or at least minimally protected. While you are at it, you should identify information on your intranet that nobody needs to see. Now I am getting into Bob Boiko's talk "Leading with Information". That deserves another post.

Facebook's "Network" feature supports workplace networks. This allows a user to take their profile (that he owns) and use it within a closed community. The same profile can, at the same time, be used in external communities. When the employee leaves the company, he just leaves the network. All the other aspects of his profile stay with him.

I guess it all depends on what you hope to achieve in your intranet. If you want to provide tools to facilitate specific workplace functions and information, then a closed intranet makes the most sense. If you are trying to create communities and build social and professional connections, you can't beat the Internet.

I just saw an announcement for a new integration between OpenCms and the Java based commerce system KonaKart. The integration is implemented as an installable OpenCms module that connects to KonaKart over a SOAP API. For those of you who are new to KonaKart, it is free to use but is not open source licensed. However, many of the underlying components (such as Struts and Torque) are open source and customers are free to tinker with those. Another interesting aspect of KonaKart is that there is a straight migration plan from the popular PHP commerce system osCommerce. The database structures are identical.

Commerce is not entirely new to OpenCms. I remember seeing shopping functionality on The North Face website (an OpenCms reference site) but it appears to be removed (probably because of a channel conflict with their retail partners). What caught my eye, however, is the amount of momentum OpenCms seems to be having. With two, high impact, big releases (v6 and v7), OpenCms has brought itself back into the limelight after losing mind-share to the new generation of Java based WCM platforms (Magnolia, Jahia, Alfresco). I think adding in-context editing has narrowed the usability gap between OpenCms and the newer products. Other new features like WebDAV have also played a big role. Plus, OpenCms is considerably less expensive (there is no "Enterprise" version to buy. All the revenue comes from support). Support packages from Alkacon are relatively inexpensive and provide enough of a safety net to molify the risk averse CIO.

If you looked at OpenCms a couple of years ago and found it less exciting than its newer peers, you may want to take another look.

I am sitting on the plane on the way back from a wonderful time at CMF2007 (pics) in Aarhus. Thanks to Janus, Sara, Flemming (my guardian angel), and the rest of the J. Boye crew for putting together a fantastic conference.

Before taking the trip, I made some changes to my computing toolkit to help me be more productive in the air. For those who don't know me, I am a proponent of server side tools for managing information. I use services like Bloglines for reading blogs, Wikis and Google Notebook/Docs for writing, and del.icio.us for bookmarks. Ideally I should be able to log onto any computer, connect to the Internet, and have everything I need.

The first change that I made was to migrate from my beloved Bloglines to Google Reader. While, I prefer the functionality and behavior of Bloglines to Reader, the addition of Google Gears makes Reader a perfect online/offline tool. I can still access my feeds from any computer but I can take my little slice of the web with me when I am offline. According to feedburner, my immigration appears to be on the tail end of a trend. The Reader wedge of the subscriber pie chart grows in proportion to Blogline's decline.

I also installed the blogging client Ecto, which I am finding preferable to the Blogger web client because it adds little touches that are difficult to reliably support in a cross-browser web client. If it were not for packed airplanes with coach seats that are too small to work in, wasted time in the air would be a perfect place to catch up on writing blogs. From a business class seat, or at least Economy Plus, Ecto would be even better.

And with that, I will dig my laptop out of my chest, power down, and watch the in-flight movie.

If you run a Plone site, you may find yourself envious of PHP WCM systems that are so easy to host on cheap, basic hosting plans. While many of the PHP based WCM products are designed to run on a shared hosting plan, most hosting providers don't even know what Zope is and don't want it on their servers. You may have been burned by the Zettai implosion and have been afraid to trust another Plone specialist. Maintaining a single instance of Zope on a leased server is not hard. You just need to know about packing the database and other administrative functions. The only hurdle is the need for basic server administration skills (monitoring, security, backups, etc.) that many small companies tend not to have... at least not to the level that you need.

Things may be about to change. Jarn (formerly Plone Solutions. They changed their name as part of the transfer of the Plone name to the Plone Foundation.) has published their framework for Plone hosting. From a technical perspective, this may be an even more generous move than changing there name. If hosting providers pick this up and use the technology as a way to expand their offering, Plone may see an adoption trend similar to what Mambo saw when it became installable through Plesk.

A Mambo-like growth spurt is probably too ambitious. Zope tends to need more resources (memory, in particular) than your average PHP based system that can run on a stingy VM or shared host. But still, there may be a noticeable increase in options. On the Plone hosting page, there are 6 providers (including Jarn). It will be interesting to see if this list expands as a result of Jarn's move.

eZ Systems recently announced the alpha release of eZ publish version 4. If you are pleased with with eZ Publish's functionality, but your in-house PHP programmers are turning up their noses for its lack of PHP5 support, this will be some welcome news.

eZ's earlier stance was to move ahead with functional improvements before making the platform PHP5 compatible. However, having addressed some usability concerns with their in context "Web-In" interface, eZ turned their sights towards PHP5 support which several other PHP based WCM platforms (such as Drupal, , TYPO3, Modx and SilverStripe) already have. Joomla! does not anticipate PHP5 compatibility until release 2.0 (Joomla! just announced a release candidate of version 1.5 so 2.0 may be a ways off).

Part of the process of adopting PHP5 is the migration of eZ Publish onto their PHP framework eZ Components. This will bring the products closer together technically to allow the same development effort to improve them both. All the eZ Publish installs will help test eZ Components. Code in eZ Publish that is redundant with code in the eZ Components framework will not be maintained in future releases.

While the PHP5 move is big, it won't have much impact on most developers. Most basic eZ Publish implementation work is done in their templating language that effectively abstracts PHP code out of the presentation layer. On the plus side, however, early reports indicate that adoption of PHP 5 has improved performance considerabely. Readers may recall my reporting that performance was quite slow without optimization.

The Bricolage list has been quite active recently with announcements of new sites and a good discussion about integrating Bricolage into a dynamic presentation tier. You should definitely check out the recently re-launched SportsNet CA. The home page is very dynamic with lots of multi-media and rapidly changing content like sports scores.

There was also an anouncement of a Bricolage community newsletter called Output Channel. Pretty good for a project that was left for dead by one reviewer.

One of my work alumni lists just sent out a link to this video about an 8 foot multi-touch screen. Wouldn't it be cool if you could use one of these to manage your website?

Here is a very good article about website design for utility over beauty. To quote:
After all, this is a media company whose magazines, books, products and programs feature ideas about attractive and tasteful lifestyles. Why not a beautiful Web site? "That was a big mistake," Wenda Harris Millard, the company's president of media, said this week during a panel discussion at Advertising Week. "We put beauty before utility." She said the front page, with its video player and jazzy graphics, included only about five links to actual content, "so the things people were looking for couldn't be found."
One of the many Web 2.0 trends is the rise of information over form. Back in the early days of the web, I remember people trying to duplicate a paper experience on the screen. Then, websites became video games challenging users to explore to find what they needed. Now it is all about the information and getting to it as quickly as possible.

And THAT is why the left navigation on my website gets pushed down to the bottom of the page on earlier versions of Internet Explorer. :)

I am counting down the days until November 6th when I will be in Aarhus, Denmark attending cmf2007. I have wanted to go for the past two years but could not justify the trip while working within a U.S. focused company. This year Content Here International is going to be there in full force. My schedule will be full too. On Tuesday, I will be teaching a tutorial on open source content management and portal technologies. On Wednesday, I am going to present a session on different patterns for deploying a web content management system. For a sneak preview, I explore some of the concepts in this blog post. On Thursday, I am moderating a track on open source CMS.

What makes CMF conferences different from other events on the circuit is that there is much more interaction. In most conferences, people pop-in, give their presentations and then jet out. At CMF, you have all the big names and everyone hangs out together at well organized social events. So, if you can't get your question in as the speaker is disconnecting from the projector and packing up his laptop, there are many other opportunities over drinks and food. Hopefully, I will see you there too.

After you watch a couple of vendor demos, it doesn't take long to realize that the performance of the demo (how well the presenters know the product and how well they understand and connect with the audience) plays as much a part of the product impression as the quality and the capabilities of the product itself. Given that the sales team probably is not going to be around during your implementation or when your users first start using the system, this should scare you if you are basing your selection on the product demo. While it is important that a software vendor cares enough about your business to put some thought and effort into showing you the product, you also want to build your system on the the most suitable product. Here are some tips to manage vendor demonstrations that will isolate the important aspects of the vendor and the product and filter out the extraneous information that may confuse or distract you. For those software vendors out there, I hope that you read this and also Tony Byrne's advice. Â For people selling and evaluating open source, there are some slight nuances that I will mention at the end but probably cover more thoroughly in a different post.

PreparationA successful demo is all about preparation. You need to prepare the vendor (or systems integrator or in house staff if you are evaluating non-commercial software) with the information they need so they can do their best. You also need to prepare the audience on what they should be looking for.

• Only do demos with a short list of vendors. Work with someone who knows the market to give you a short list of products to look at. That doesn't mean asking someone "what are the best CMS." If they know anything, they will tell you that it depends on your requirements. If they have an opinion. Well, it is just going to be that: an opinion. You need to focus on a short list for two reasons. First, if the vendor knows that he is in a field of 10 candidates, he is not going to invest as much in the demo. He will have a junior sales team give a generic demo. Second, when subjected sit through 10 demos, your staff will not invest as much of their attention in evaluating each product and they will start to muddle the products together.
  
• Clearly define what you want the demo to show. Because content management systems (especially web content management systems) are so flexible, a demo should be a prototype that you define according to your requirements. Just like a prototype, you need to clearly specify what it needs to do. The approach that I find the most effective is using scenarios that describe tasks that need to be accomplished using the system. The demo should show how the user would accomplish that task using the product. The demo should also recognize the constraints introduced by your architecture. The vendor should not know you features that would not work in your architecture. Neither should they show features that you don't need. The demo should show your content. Ask the vendor to configure a content types that matches the the most complex content type in your content model.
  
• Validate that the vendor understands your requirements. Have the vendor prepare a written response describing how their product can support your scenarios. Review it and give them feedback with ample time to adjust their demo in case they misunderstood what you need.
  
• Prepare the audience. Prepare your audience for the demo by telling them what they should be looking for. A scorecard that lists the scenarios is useful for keeping people's attention on their needs, not gimicky features. If the audience does not understand basic content management theory (separation of content and layout, re-usability, content lifecycle, etc.) address that before the first demo. Vendors are actually pretty good at explaining that stuff but there are more effective uses of their time. Â Also, vendors tend to up their game when the realize they are dealing with a sophisticated audience.
  

During the demoThe demo should use everyone's time as effectively as possible and should be organized to ensure that vital information is communicated to the right people.

• Limit company background information. The vendor should be able to introduce their company and make the case that it is a stable company, it gets content management, and knows your industry. However, you need to contain the amount of time that they take to do it. They should be able to build a level of credibility and comfort with the audience but not infringe on the time they have to talk about their product within your context. Hopefully your short-list exercise already pre-qualified the vendors along these lines.
  
• Mind your manners. Even if your corporate culture thinks it is OK for staff to attend meetings in-body only, keep distractions to a minimum. Ask your audience to put aside their email, blackberries, and cell phones and pay attention. Give the vendors every opportunity to engage with the audience. If the vendor is missing the mark, don't tune out. Instead, help steer them back on course. If you can't do that, politely end the meeting as quickly as possible and be happy that you were able to eliminate an option in a very hard decision.
  
• Mark your scorecards. Without making it feel like a Bingo hall, have the audience take notes in their scorecards so that they remember what they saw and their impressions. By the time they have gotten back to their desks and answered their first of fifty waiting emails, they will have forgotten half of what they saw.
  
• Break up the meeting. A thorough demo is enough to tax anyone's endurance. Not everyone needs to hear everything and people tend to lose focus after sitting for long periods of time. I usually break up demos into three main sessions. The first is the company background and functional session that all the stakeholders should attend. This is when the vendor walks through the scenarios and helps business users visualize using the product to get their jobs done. The next session is the technical session that shows what is going on behind the scenes and how the system can be customized and integrated. All the business users that are still awake can leave for the technical part. If they are asleep, leave them alone and let them dream about life with better content management tools. They can use the rest. The third session is the project management and licensing part where the vendor talks about the licensing needs, cost, and professional services. Your project management people and tech leads need to be part of the discussion. Everyone else can go back and extinguish the fires that have probably ignited during their absence.
  
• "Yes" is not a good enough answer. When you ask if the system can do something, don't let the vendor get away with a simple "yes." Have them show it. And if they are not prepared to show it, have them describe how it would work and how much effort it would take to get it to work like that. You could also ask to speak to other customers that are using the product in that way.
  

Follow upDon't let wait long to get feedback from the audience. It doesn't take long for people to forget. Follow up and plan the next steps as soon as possible.

• The post mortem. As soon as possible, get everyone in a room and have them express their observations and impressions. Ask them what they didn't see. Hopefully, they have notes on their scorecards. There were probably some scenarios that were not adequately explained. Get this information so you can follow up with the vendor.
  
• Schedule follow ups. Talk through what additional information is needed with each of the vendors who earned further consideration. For the vendors that didn't make the cut, explain why. If the demo was a disaster but you think the product still has potential, you could give them another chance or you could take it as a sign that they are not prepared to support you. Remember, after the contract is signed, things are only going to get worse.
  
• Prototype. If there is a question about something, build a prototype and allow users to bang on it. Different vendors will have different policies around this. Some create hosted sand boxes and allow business users to experiment. Others provide trial versions of the software so that a customer can attend training and try to build the prototype themselves.
  

Conclusion

Demos can either clarify or confuse, inform or misinform. If run properly, they can be the most important part of the selection process. At the end of the day, both you and the vendors are after the same goals. They want customers that are successful with their software. You want to be a customer that is successful with their software. However, that doesn't mean that a sales team can't get swept up trying to win a deal. It also doesn't mean that business users will not lose sight their goals when distracted by flashy features and a compelling demo performance. Be up front with this and try to work together to achieve this goal.

What about open source software? For the commercial open source products out there, this advice still holds. You just want to be even more sensitive about using the vendors time efficiently because they have less to gain in terms of licensing revenues. Assign some of your technical staff to dig around the product (and the community) for themselves. Â If a commercial open source vendor is able to invest in large sales teams, you can be pretty sure they have a pricing model (around support and maintenance) where they can collect revenues that are equivalent to commercially licensed software. Either that or they haven't had to think about building a sustainable software business yet. For community-based projects, you are not going to get a sales team. You should form an internal team (or pay a systems integrator) to build the prototype and play the role of the sales engineer. You probably need to do more homework to decide what platform(s) you should evaluate and be even more diligent in documenting your requirements. Â Otherwise, your developers will get drawn to nifty architectures and technology buzzwords and neglect what your business users need.

I was Skyping with someone a couple of days ago and he was referring me to a URL that he decided it would be better to type. One reason was it was not in English and I have no foreign language skills. The other reason was the URL was http://www.maatschappelijkverantwoordondernemen.be. Now that is a URL. I recently saw a presentation by David Esrati from The Next Wave where he talked about his 80-40 Rule. The basic idea is that URLs are less important because 80% of browsing starts in the search box. 40% of users are so clueless that they type the URL in the search box. If this is true, having an awkward domain name is not so much of a problem. Social bookmarking and blogs probably help too. But I assume that there are limits to acceptable awkwardness.

BTW, kudos to J Rulnick for having the foresight to register chargoggagoggmanchauggagoggchaubunagungamaugg.com after the longest place name in the United States! He gets the 80-40 rule! I think?

I was very happy to read Marc Osofsky's very well reasoned and well written article about setting content free. In the early days at a company that I used to work at ;) we had a simmering debate about whether or not to require registrations to gain access to our white papers. As you might expect, the consultants (who joined the company because they got the concepts behind open source software and Web 2.0 and also wrote the white papers) wanted to make the white papers freely available. The sales organization, whose business process centered around processing leads, couldn't see the logic of not getting contact information whenever possible. For a long time the company had a required registration and our sales guys made qualification calls to "Superman" and "Mickey Mouse." Hey, a lead is a lead. Right? Actually, the sales guys did get frustrated as you can tell from this blog post.

Web 1.0 expanded markets by allowing traditional business models and practices to be less geographically constrained. With Web 2.0, communication has surpassed the point where it can be directly and centrally controlled. By producing good content, companies are able to extend their reach beyond the realm that they can actively participate in. People download things, try them out, blog about them, and talk about them in public and internal forums (physical and digital). If they like what you have to say and have problem that you can solve, they will find you. Maybe 1 in 10,000 contact you. That is pretty good if you are reaching millions. Furthermore, the 1 person that calls has already spent a lot of time pre-qualifying himself saving you a lot of work. A great example is all the companies that put their product videos on YouTube. I am seeing more software companies making their documentation available but there is a concern that their competitors will have access (as if they don't already).

All this doesn't mean that you can forget all of your traditional prospecting work. That is, unless you have an amazing product that just sells itself. You need to keep a balance. Keep your sales guys getting their leads and working on them. Just don't constrain the power of your published information by controlling it with a pre-web mindset.

On October 18th, Bryant Shea from Molecular and I will be presenting at DocTrain East in Lowell, MA. The topic of our talk is "New Documentation Strategies For A Web 2.0 World." Here is our descriptive blurb:

The web is changing the way people consume information and creating new opportunities for documentation and other product content to reach out beyond the manual and engage users. The web is also giving voice to others who have something to say about your products. To navigate these new dynamics we must change our mindset about what documentation is, our relationship with our audience, and our control over the information. This session will introduce technologies for reaching and conversing with the your audience to create knowledgeable and passionate users. We will cover blogs, podcasts, annotations, and wiki technologies and how to turn a vocal community into an ally rather than threat.

I just got off the phone with Bryant and we were pretty excited about how Web 2.0 trends and concepts are transforming the world of technical writing and communication. Come and join us to learn more.

I subscribe to a bunch of open source WCM mailing lists. Occasionally, someone announces a new site that he/she built on top of the platform. When I read this, I usually tag the site on del.icio.us with a tag like <cmsname>gallery. For example: "bricolagegallery". Many open source WCM project sites already have nice reference site galleries with descriptions about the technology used. I find del.icio.us tagging useful for sites that are not on the public galleries. Here are some tags that you might find useful:

• Bricolage
• Daisy
• Drupal
• HippoCMS
• eZ publish
• Magnolia
• Plone
• Typo3

If you have a reference site that you would like to put up on a CMs project gallery, you should send an email to their mailing list. If there is no gallery or you just want to put something up right away, tag it in del.icio.us.

I was just reading CMS Watch Commentary today and noticed Alan Peltz-Sharpe's post about the Department of Justice suing Accenture for allegedly (who are we kidding, we KNOW they did it!) colluding with a software vendor and recommending the product based on kick-backs. See full story. These are the times it feels very good to be a vendor neutral technology strategy consultant. The collusion between systems integrators (and some large analyst firms) ranges from trivial to flagrant.  Even if there are no monetary kickbacks on  a software deal, there is usually some kind of bias.  A systems integrator (or more accurately, individuals on a sales team) is going to pitch the product that they know best in order to reduce their risk.  In fact, you don't necessarily want a systems integrator to propose  a solution that they are going to learn on your billable time.  Software vendor partnerships may exert pressure to prioritize a certain solution.  My recommendation would be to accept that systems integrators are biased (that they need to be biased) and put their recommendation within that context.  Maybe talk to a couple of SI's that specialize in different products.  Or, better yet, talk to someone like Content Here who can afford to be vendor neutral and have them connect you with the right technology and the right integrator.  There's my bias talking!   Seriously, it was probably foolish for the Department of Justice to expect an unbiased recommendation from Accenture. I just hope they didn't waste too many tax dollars buying it.Â

Outerthought just announced the official release of Daisy CMS: version 2.1. For those who are not familiar with Daisy, it is a fairly simple, easy to use Java based WCM platform. The front end is styled after a wiki although it supports more comprehensive WCM functionality such as structured content types, decent access control, and workflow. The repository is de-coupled and is accessible through a ReST style interface so the more ambitious or Cocoon-phobic (the user interface is written in Cocoon that has a steep learning curve) can write their own management interface and front end.

Daisy is primarily used for basic informational sites, intranets, and knowledge bases. Some companies use it to create documentation because of its XML oriented architecture, its book publishing features, and also its powerful versioning and localization functionality. Thanks to a partnership with the Belgian systems integrator Schaubroeck, Daisy is widely used for local and regional Belgian government sites. Daisy development is managed by Belgian systems integrator and software developer Outerthought which also sells support packages on the platform.

This new release is supposed to be easier to configure and manage (thanks to a new Spring based runtime container) and includes a very cool visual version diff'ing tool. Unfortunately Daisy is still missing user input validation out of the box. You can only set whether a field is required and the size of the input box.

If you have been looking for a basic, mature Java WCM and have been turned off by the complexity (in terms of user interface, architecture, and social dynamics of the community) of Apache Lenya, you should give Daisy a look.

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.

There have been many observations about "consumerization" (BTW, I thought I made that word up but it looks like Gartner beat me to it) of enterprise software making it simpler and more appealing to casual users. This is mostly in terms of user interface but I think it also applies to installation and management. Enterprise software is being held to a new standard by business users who are no longer satisfied with the explanation that the software stinks because it is "enterprise grade."

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.

The GA release of Plone 3.0 is right around the corner (due out August 21) and there are many new features to look forward to. Unlike 2.5 which was a primarily architectural release, 3.0 focuses on the user interface. Jon Stahl does an excellent job of summarizing the key improvements in his post "8 Really Cool Things About Plone 3." You can download release candidate 2 here. The features that I think are the most significant are:

• versioning, staging and locking
  
• more granular workflow control
  
• a dependency manager called "link integrity" that prevents broken links
  
• and lots of improvements to the Kupu rich text editor.