Plone Strategic Planning Session
[Added links to Jon and Alex's blogs]
I am heading back home from Mountain View after spending a day at the Plone Strategic Planning Session where 50 Plonistas are meeting for three days at the Google campus to discuss the future of Plone. Kudos to the Plone Community for proactively thinking about growth and improvement when things are going well for Plone. Too often these discussions happen during crisis when options and opportunities are limited.
Yesterday (day one) focused on "marketing" and today is about technology. Tomorrow attendees will organize the action items that came out of the first two days. Jon Stahl from One/Northwest did a wonderful job of organizing the event and directing the sessions (he even got a Kentuckian to "twinkle" - you had to be there). The Plone community is lucky to have leaders like Jon. That Jon comes from a non-technical background shows how the Plone community has been able to attract, engage, and leverage non-technical people. Plone co-founder Alexander Limi's assertion that he is not a technologist (although he is a closet geek) has helped the Plone culture be more inviting to non-technologists and give them pathways to leadership. This aspect of the Plone community is somewhat rare in open source software (and most commercial software too). I would say that the closest thing is in the Joomla! and Drupal communities that have active marketplaces for designers to sell and share themes.
The biggest issue that the group struggled with is the one that confounds the whole content management industry: is a CMS a framework or a product? This came up a number of times in pre-conference blog posts and email threads as well as during exercises like composing elevator pitches. The elevator pitch exercise turned up another industry-wide puzzle: what is content management? I, personally, dislike the term content management. "Content" is too vague and "Management" (in my mind) is a negative word (guess who works for himself). "Content Management" implies that content is a liability and needs to be controlled. It sounds too much like "Waste Management" or "Risk Management." However, it is convenient that the term is widely known and immediately brings about a sense of understanding. Alas, I digress. Back to Plone...
There was a good discussion about competitors and differentiators. Drupal, Microsoft Sharepoint, and Alfresco were identified as the biggest threats. From an emotional perspective, Drupal got the greatest amount of attention because the long-standing rivalry and that Drupal has been so successful in the non-profit sector where may of the Plonistas work. Alfresco and Sharepoint are newer and the Plone community is still learning about where they fit in. Plone has a broad set of uses and both of these products certainly encroach on some of the territory that Plone has marked out. Sharepoint, is very compelling for intranets and collaboration. Aggressive pricing by Microsoft, especially for non-profits, trims Plone's edge on total cost of ownership. However, Sharepoint is not a good answer for building traditional websites where Plone is effective.
Joomla!, Drupal and low-end commercial tools like Expression Engine, City Desk and Adobe Contribute are the obvious competitors for building basic websites. In order to reach the broad, low-end market, a theming community and a shallower learning curve would help Plone. Open source products that were noticeably absent from the discussion were TYPO3 and eZ Publish. Although less so in North America, TYPO3 has a nice network of agency style consultancies that can efficiently build highly branded websites on the platform. TYPO3's default install with all of the back-end modules enabled makes the product easy to dismiss as complex and ugly. But most TYPO3 customers see TYPO3 only after it has been tailored to their needs. eZ Publish has the advantage of commercial style support options and productized bundles that are targeted to different market segments and industry verticals. Both of these qualities would help Plone be more accessible to a broader market of buyers.
Alfresco was also on the radar and there are good reasons why the Plone community should be paying attention to it. While Plone's out of the box user interface is much more refined than Alfresco's, Alfresco has a number of architectural features that make it a better general content management framework. Alfresco's repository services are more open and advanced than Plone's and most large companies developing custom web applications will be better equipped to build and support them in Java than in Python and Zope. I think that Plone's Zope architecture will frequently qualify Plone out of large corporations that think of the world in terms of "Microsoft" and "Java." There was an acknowledgement that large, established IT departments tend to be hostile to Plone and chances are better when business owners run the selection process. That is not to say that very large companies have not successfully deployed Plone in important content management scenarios. Just look at Novell and the CIA. There are also some other big companies that are in the process of major Plone deployments.
Many within the Plone community feel that there are better Python frameworks for building general web applications so maybe this is an area that Plone should not try to compete in. The general consensus is that Plone developers should try to integrate with other applications as much as possible rather than build everything on Plone. I am sure that they are talking about technical tactics for enabling integration strategies today during the technical session. I would expect that there will be a discussion about better mechanisms for creating and consuming RESTful APIs and strategies for replicating content out of the ZODB.
I am really happy that I attended the Plone Strategic Planning Session. It was good to see the Plone community in action working together to solve difficult questions. It will be interesting to see how these ideas get distilled into a strategy that is easy to organize behind. More important, however, will be how the Plone community is able to execute this strategy.