lundi 6 septembre 2004

Bricolage and content delivery This balanced, well-written article on Bricolage contains a point that is worth exploring in the Zope community. The downside to application servers is that, because they both manage and deliver content, your choice of delivery technology is limited to the technology choices of the software developers. With Plone, for example, you have to use Zope to serve content to the final audience. From this, some questions. Do people feel this is, in practice, accurate? Is there any reasonable audience that would like the option to separate content management from content delivery? Should Zope 3, for example, contemplate this perceived demand? 10:18:33 AM   comment []

"Market prospects growing for open source content management" Sure, when an article has your name in it, ya' gotta pimp it. :^) In this case though, the relevant part is in the sidebar. Forrester senior analyst Bob Markham has a sidebar in this article that is interesting reading for those trying to build the "whole product" (in Crossing the Chasm-speak) around Zope, Silva, CPS, Plone, etc. When reading this, I felt that the primary issues Bob described were veto issues. Meaning, they aren't things that will win a bid, they are things that will lose a bid. Customers don't get thrilled about the license scheme their new CMS will put on their organization. They don't rave about how lucrative is their vendor's business model, nor the incredible support terms. Instead, they move you through the tender to the short list, then eliminate you due to the absence of these items. I view these issues, then, as non-differentiators. They are like the software architecture of Zope: a base on the bottom atop which a competitive offering is built. These issues are loss-centers, not profit-centers, and are the base atop which our successful business models must be made. But these issues are not differentiators. Thus, just like we pool our resources on the software architecture, we should pool our resources on the business architecture: support, maintenance, core training materials, perhaps core marketing materials. These are all checklist items that don't provide much differentiation, don't provide much profit margin, but do generate expenses. If this is true, then it brings up an interesting question: What is an open source business model? To date, most answers to this question revolve around risk elimination. Companies take steps to replace the bazaar with the cathedral, including mixing in closed or half-open software as a way to get the "effective, profitable business model" that Markham describes. But this business model is aimed at the ROI interests of the investors and only secondarily at the customers' goals. If a customer sees benefits from open source software, should those benefits be increased or decreased by an open source business model? I feel there is market demand by folks that value open source software. I also feel this market would react positively if those same values and benefits were built into the business model of their vendor. I think the first step to answering Markham's challenge ("There isn't a good model to make money at this yet.") is to eliminate items on the expense side of the equation. Although most VCs look at huge profit margins as the measure, Markham's challenge was for a profitable business model, not a Google-type wealth engine. Thus, attacking the expense side is a good first step. We also reduce complexity, meaning small companies get to continue participating, since they don't have big staff to administer overhead operations. We then package this up, explain it to the market, and find the customers that want to be placed ahead of the investors in the food chain. Most importantly, though, we retain the small software shop as the value engine. To answer the question above: An open source business model is one that advances the benefits of open source software, not one that retreats. The remaining issue, then, is a specific proposal for putting this into practice. More to follow. 10:14:00 AM   comment []

The practicalities of content reuse James Robertson from Step Two Designs has a long article up explaining the much-sought customer goal of content reuse. He explains the different things this can mean and how these approaches have a dark side that make them painful in practice. I'm on a project where we are trying to do multisite publishing in Plone. The effects of this are subtle and speak for the need of some Deep Machinery. 9:34:49 AM   comment []

"A replacement for traditional object models" Kimbro Staken is the creator of Syncato, a Python-based "content management system for the little things". "Syncato is a micro content management system designed to extract the maximum potential from the content of your data. All data in Syncato is stored as XML within a native XML database and is searchable using XPath." Jon Udell has written about Syncato on his weblog at InfoWorld. I spent the weekend working on Berkeley DB XML, and Python, and Syncato. It's all quite interesting. Specifically, I'm interested in hooking up Syncato or a Syncato-like thing to Zope 3 as a basis for XML support in the world of Zope. In trying to explain this approach, I came across an interesting paragraph Kimbro wrote on the Syncato mailing list: I also wanted to experiment with XML as a replacement for traditional object models and while Cocoon does that to some extent it doesn"t go nearly as far as I wanted. In my model instead of creating a Java bean to represent some object, you just have an XML instance and use XPath to manipulate it. This way there"s no miss match between persistence and in memory models(i.e. no mapping) and your model is loosely coupled to the language you"re using. Note: He has strong experience with Cocoon and XML database integration. Kimbro's philosophy is refreshing as an extra point of view. Zope 3 is adding a strong component architecture with more formal contracts about schemas and more rules for objects, which of course Python has always eschewed. Zope 3 needs things things as its scope is to build a pluggable universe of managed software. However, should this approach reflect up into content types in a CMS? I don't think that this is an automatic yes. Instead, I hope to examine more about the Kimbro approach, to delay as long as possible constraints placed on content. You never get your content type right the first time and you can never predict what you want to do with those bits in 3 years. I also find the microcontent approach interesting. It is worth a read at the Syncato web site. 9:30:34 AM   comment []