Jan 02, 2007
Happy New Year!
I just heard about OpenEngagement: a Plone bundle designed for the accounting industry. OpenEngagement provides document and web content management services and has a portal to be used to share documents with clients. OpenEngagement's revenue model is based on support contracts and a hosted option.
The initiative appears to be backed by CaseWare, a provider of specialized assurance and reporting software to support the delivery of accounting services. There is an integration with CaseWare's flagship product (WorkingPapers) that allows you to browse the document repository from within WorkingPapers.
This seems like a good use of a community based content management project like Plone. For minimal cost, CaseWare is able to provide their customers (and prospects) with decent content management functionality. The small to medium accounting firms, which make up a large portion of the accounting industry, are traditionally under served in this area. The support option is probably very desirable because many of these companies have minimal in house I.T. resources.
Dec 29, 2006
We just posted Episode 4 of the Malcontents podcast. In this issue, Bryant and I talked about the Fall CM Professionals Summit and the Boston 2006 Gilbane Conference. Topics included Localization and Blogs and Wikis in a Knowledge Management context.
Dec 20, 2006
Most software architects are idealists at heart and think in terms of clean UML diagrams. In approaching a content management project, their tendency is to apply best practices in software development and design an architecture that supports highly structured and reusable content and separates concerns of management (authoring, workflow, and persistence) and delivery (formatting, personalization, and branding). The resulting picture is a "pluggable" architecture of components that can be swapped out as needed. As a software architect myself, I too am drawn to this model and, in many cases, it makes a lot of sense. However, most content management software applications try to play on both the management and delivery sides of the content management problem. If you want to achieve this de-coupled, pluggable architecture, you will most likely need to behead your CMS and put another delivery tier in front of it. Should you cut off the head to spite the face of your CMS? Maybe, but here are some things to think about.
Where a software architect's "separation of concerns" is on functional lines, a business user's concerns are task oriented. A business user's task is to produce content. But they don't just write. They write, review, write, review, then submit. And these loops are not long workflow steps involving many people. They consist of tiny cycles of typing and previewing. Interestingly, this is how software programmers work nowadays. They code a little, then they test. It has been 20 years since programmers have been asked to write a whole program and then send it over the wall to see if it worked. Now we give programmers IDEs (Integrated Development Environments) so that they can write and review (test) in the same environment. Modern software development methodologies stress continuous testing by the developers not just a separate group of quality assurance staff.
End to end CMS, which own the management and delivery tier, perform the same service as a programmer's IDE. They create a sandbox for the content author to develop the site (notice word choice here, I will talk about that later). When the delivery tier is decoupled from the management tier, this integrated environment must be custom built if it is to be provided. You need to be able to replicate the delivery sandbox and build publishing functionality to point to different delivery targets.
The other area where the concerns of management and delivery are not so clearly separated is that most users want to use their CMS to control how the content is displayed - a domain that should philosophically be owned by the delivery tier in that model architecture. This control is on two levels: at the content detail level (with layouts); and at the overall information architecture level - where the content will appear. Preview and control of the former is often easier to provide because it is simpler to push a single piece of content to a presentation template than to refresh the entire instance of the site (remember people like to preview every couple of minutes). Showing where a piece of content would appear in a search result list requires all the proposed content to be staged in the staging instance of the site.
These requirements of being able to control the the composition and behavior of the site is what I was referring to earlier when I said "develop a site." Typical needs include explicitly determining the order of lists of content and what reusable assets appear where. When the content producer is a site developer, the qualities that he must control and test do not end with the spelling, grammar, and accuracy of the text. He needs an environment that gives him a round trip preview experience of the whole site. He needs the IDE to develop the site not just a tool to produce content.
Now, in many cases, it may be reasonable to limit the scope of a content contributor to the composition of words and images. After all, your average Associated Press reporter is not able to control how his article will appear on the Daily Hampshire Gazette. If you are doing a lot of personalization, preview is also less valuable because there is no way an author can simulate all the different conditions that drive personalization rules. But this is not how your average corporate website works. Corporate websites are less query based and programmatic and more explicitly and manually composed.
Systems that publish to different channels and have complex delivery logic (where preview is less useful) tend to make better candidates for decoupled architectures because of the investment that it takes to develop the delivery tier. These sites have lots of custom code (or configuration files) that has evolved over time and is extremely expensive to port. In fact, it is usually hard to even estimate the time to port these applications because no one really knows the rules and algorithms. The behavior is totally undocumented except for in the code itself.
So if you are designing your dream architecture with different pluggable tiers and your business users are hassling you about preview and control, you need to ask yourself "is my delivery tier sophisticated and complex enough to warrant having to build my own?" If it is, you need to be able to explain to the users that the delivery tier is a complex application that drives the presentation and their job is to fill the tank. You can give them a single page simulated preview and they can share a full staging instance of the site if they wanted to review the whole site before a mass publish. If they don't buy it, you can build in the additional integration to support "site developer" tasks or wait for the next project to design that precious architecture.
Dec 18, 2006
Specialized search engines that focus on a subset of the web are becoming increasingly popular. These services can reduce problems with ambiguous terms (such as the word "pool" that could reference a parlor game, something that you swim in, a group of persistent connections to a database...) by focusing on a subset of the web. Google is enabling this specialization through its Co-Op technology. At least that is what Ric Shreves from Mambo specialist Water and Stone (they also work in WordPress, Drupal and Joomla!) is using it for. Water and Stone has recently launched CMS Search, which indexes around 75 open source CMS project sites.
This looks like an interesting tool. There is a "refine" feature that limits search to a subset of sites. Try using this to search for a feature and then drill down to see what the community or the documentation of a project has to say about that feature. Unfortunately, this refining feature only works with projects that Water and Stone specializes in.
Dec 11, 2006
Now that the web is about to move onto 3.0, it is about time for the office to get to 2.0. Eric Severson has a nice post on the Gilbane blog about Office 2.0. I will give you a hint, it has nothing to do with Microsoft.
Dec 10, 2006
If you are considering open source software, the community could be the "x-factor" that determines your success with it. The community will influence your experience of the software and shape the application's future. If you are used to commercial software selection, the concept of "community" is probably alien to you. You may be used to reading analyst reports about market share and corporate financials. "Community" feels squishy and qualitative by comparison. Even though the information that can be used to evaluate a community is visible, it takes some work to gather and interpret it. Here are some strategies that I use.
General Activity
Activity can be measured in email and IRC volume, bug activity, release frequency, and source code commits. SourceForge rates project popularity on several statistics. However, this rating system is not particularly reliable because many projects just use SourceForge as an inexpensive place to distribute the software. When a project does not use SourceForge's mailing lists, forums, or bug tracking tools, SourceForge's quantitative metrics are less than useful. Also, the activity of certain consumer projects, such as the Gaim instant messenger client, eclipses enterprise software projects. Ohloh gives a nice snapshot of code metrics such as top contributors, the amounts of comments in their code, the overall amount of code. Ohloh even has a neat little feature of how much it would cost to build the project from scratch. Unfortunately, not all projects are tracked by Ohloh.
The larger open source projects have regular events such as conferences, user groups, sprints, and even recreational outings. Social activity on a project shows personal investment within the community. Stronger relationships between developers usually translates into better communication and more potential for collaboration and negotiation. This is a good sign but not all good projects have a happening social scene.
For me, the most valuable resource is the bug list. While in the commercial software world you hope to be blissfully ignorant of bugs, in the open source world the bug tracking system is where people discuss possible improvements on the system as well as defects. Active bug lists mean that people are using the software and care about it. An issue that just sits could mean either the project does not have the developer bandwidth to enhance the software or that the leadership disagrees with the feature.
Vision and Priorities
Looking at volumes of bugs and identification/closing rates is informative but it is even more helpful to read some of the issues and ensuing discussion about them. That will give you an indication of the project direction. Depending on how you plan to use the software, the direction may be even more important than the current state. Many projects also publish a project roadmap that shows what features will be added and when. Enhancement requests that are considered important to the community wind up on the road map. Enhancements that conflict with the community's vision get rejected. These decisions indicate the communities priorities better than any other information about the project. While, as in all software development, priorities get shifted and there may be delays, it is useful to look at the project's track record of checking off items on the roadmap and meeting milestones. You want to know how reliable these road maps are and understand why features are not on the roadmap.
Leadership
The most successful projects have charismatic and energizing leaders. However, hinging the future of a project on the participation of one person is dangerous. If the project leader burns out, loses interest, or is hired away from the project, will the project survive? The true health of a community is best demonstrated by its ability to withstand a change in leadership. However, many projects have not been tested in this way. I look for projects with a solid secondary tier of contributors and a track record for promoting and recognizing people that show leadership qualities. It is from this pool that the next leader will emerge. Many projects designate managers for every release so contributors can test their mettle in leadership situations. Some projects create sub-teams with their own organizational structures. Others have a rotating leadership team.
Execution
Reliability and quality are not achieved through dedication and good intentions alone. In order for a project to produce good code, it has to have good processes that people actually follow. Usage of the bug list and roadmap show that the project is able to prioritize the work. Having development standards and adhering to them will ensure that the software will meet the vision. The better projects will have clearly defined coding standards and rules for submitting code. For example, many projects require developers to run unit tests and include the results for every code submission. Project leadership needs to be strict in enforcing these rules without discouraging potential contributors. Many healthy projects also have a strong social order where violators are "called out" on the mailing lists for their transgressions. The level of hostility depends on the culture of the project. Some projects are combative on the surface but there is an underlying layer of respect (a little like some families). Other projects are just downright caustic and push people away.
Participation
The better projects encourage and get participation from a functionally diverse community. Participation is not limited to submitting code. Non-technical members can write documentation, test the software, organize events, and answer questions on the mailing lists. Blogging about the software is also a useful form of participation. Projects should be inclusive and encouraging of people that want to participate. From talking with experts that study this stuff, I have learned that turnover within the community is actually a positive thing. New members bring new ideas and perspectives to the project. They test the software in ways that existing users did not anticipate. They also test assumptions. Newbie (n00b) questions may seem tedious to project veterans but they are vital to the health of the project. Projects that do not recognize this value and respond with an "RTFM" (Read The F*** Manual) response do so at their own peril. "RTFM" might be the right answer but there are more polite and helpful ways to say it. Look for the way the community responds kindly to n00b questions.
Economic Ecosystem
Are people making money off this project? If there is no money to be made, people will gravitate to other interests that pay the mortgage. Some projects are commercially sponsored, so developers can expect a paycheck. Some contributors are paid by their employer (that uses the software) to improve the software. Other ways to make money in open source are consulting, support, training, hosting, and writing books. Look for people offering these services for the project. If you can't find any, the community may not be sustainable.
Unfortunately there is no single indicator of community health and strength. I am sure that one day there will be some statistical algorithm that looks at all of these data points (and more) along with project success rates to come up with a single score. However, this will not tell you how well the community will serve you. The best way to evaluate a community is to engage in it with these factors in mind. Build relationships with community participants. Also listen for the gossip. Virtually every big event that has happened within an open source project has been preceded with rumblings either on the mailing list or in casual conversations. Once you join a community, stay as engaged as you can. This wil
l keep your finger on the pulse and give you more leverage and access when you need something.
Dec 06, 2006
While most WCM products and projects are focusing on AJAX technologies to deliver a better editing experience from a browser based interface, there are a couple of projects looking in other directions. Yesterday, Wyona CEO and Apache Lenya Founder, Michael Wechner showed me a new approach he is working on: Yulup and Yanel. Yulup is a FireFox plugin that provides editing tools for web assets that have been Yulup enabled. Yanel is a trimmed down CMS interface that Yulup can talk to.
If a user has Yulup installed, he sees a special icon on the top right of his browser. This icon will indicate if a page is Yulup enabled. If it is, the user will be able to execute actions like checkout, open, save, or whatever else is enabled at the server. Yulup uses FireFox's WYSIWYG HTML editor or more sophisticated users can edit the HTML directly. The demo that I saw had a static HTML website but I could see how this technology would be capable of handling more structured content. Dialog boxes written in XUL perform functions like repository browsing and file upload.
Behind the scenes some interesting architecture is at work. Pages are enabled by adding an XML tag to the content. This tag tells Yulup to ask Yanel for a resource file that tells what actions are enabled. This resource file also maps actions to different URLs and methods. In this way, different content management systems can perform library services such as checkout, check in, add, update, delete, etc. Neutron is the protocol. Michael expressed some regret about not using an existing protocol (Atom and WebDAV were considered) but these didn't have necessary features and it was unlikely that the Yanel/Yulup team would have enough sway to get them added.
This is still early technology and there are some important features to add. For example, the system needs a more sophisticated security model that limits the available actions before login. Also, details like how to implement versioning and workflow have not yet been fleshed out. You can see the roadmap here. The long term vision is to Yulup-enable many different CMS and standardize the user interface similar to how the JCR hopes to standardize content storage. As with technologies that threaten to disrupt the status quo, many projects may resist this attempt to hijack the interface and commoditize the CMS. But if this UI works for users (especially users that need to work on different CMS) it may be hard to fight much in the same way that many writers want MS Word or Outlook to be the interface to their ECM systems.
The other project that is trying to create a universal user interface for content management systems is the Apogee Project. They are building content management services on top of the popular open source IDE (Integrated Development Environment) Eclipse. This project appears to have stalled. I would give it low potential for survival because the project sponsor (Nuxeo) has its hands full porting CPS from Zope to Java and because Eclipse might be too techie for your average content editor. Last I checked, Eclipse was a 100MB+ download and good luck using it if your screen resolution is less than 1600x1200.
Developers working on a rock-solid CMS with an ugly face (of course, no developer thinks his baby is ugly), may want to check this project out.
Dec 06, 2006
If you use Blogger, you know that they have been increasingly aggressive about converting users to the new "Beta" platform. Initially it was a "pssst, we have something new!" accompanied by warnings of once you go Beta, you can never go back. Recently they put in an interstitial page making it easier to upgrade than to go to the old tried-and-true version. Well, this time, I took the plunge and I upgraded. If you haven't done so yet, you have the following to look forward to:
- The "Blogger Buzz" feed on the dashboard
- A text field on the edit post page where you can put in tags
- A better post list page. Here you can apply tags to a bunch of posts at a time
- Faster publishing
- They will merge your Blogger account into your Google account
No earth-shattering improvements but no trauma or drama either.
Dec 01, 2006
I am back at work after attending the 2006 Fall CM Pros Summit and the Boston Gilbane Conference. I think that most would agree that the CM Pros Summit was the best ever (Gilbane was also very good but that is another post). We set a record for number of attendees. The speakers knew their stuff and the audiences were all very engaged. See some photos here. Adriaan Bloem, blogged everything he saw on the CM Pros BeNeLux blog.
I thought that my round table on Levels of Localization went well. I am collecting materials for an area on the CM Professionals website (check out the new look) that describes the levels and shows some examples. I will announce here once something is up.
Nov 16, 2006
The whole reason why you started on this content management initiative is to get the right content to the right users at the right time. A CMS is not the only software that promises to solve that problem. In the good old days, many software buyers took an integration approach by presenting CMS managed content through a portal. However, by building in some content management capabilities, portal applications are moving beyond just presenting content managed within a CMS, to replacing the CMS entirely. At the same time, content management systems have beefing up their delivery capabilities and providing portal-like functionality that, in some cases, makes a portal unnecessary.
So, do you need a CMS, a portal system, or do you still need both? A few days ago, Bryant Shea and I hosted Apoorv Durga and Janus Boye to talk about that very topic.