Phil Wolff wrote on RSS per Page: Toward Weblog Portability:

We need RSS files for every archival page. If you write archives by the day, week, month or year, one for each. If you write archives by category or topic, one for each. Where there's an html page, there should be an RSS file.

One other piece: A master list, perhaps in OPML, of the RSS files. This makes structure explicit so content can be discovered, imported, and flowed through new templates. The cost, negligible. Data portability is a huge deal in enterprise apps. The worlds of ERP, CRM, databases, email, and file service all met this threshold many years' ago. Weblog engineers should step up now.

It means that the big system integrators won't be put out of their job :-) by the new potent, emerging combinations of personal publishing, team-blogs, project-blogs and other types of business blogs. In fact, the ones that learn to master faster the intricacies of blog portability and inter-operability with other type of social software and legacy systems, they may turn that competence into a significant competitive advantage of high value, as our baby knowledge economny shifts gears towards more trust-based relations of production

In a germinal essay on social software--that we wish we wrote--Smarter, Simpler Social: An introduction to online social software methodology--Lee Bryant called our attention to the striking contrast of enterprise software and social software. His brilliant analysis deserves our full attention; that's why the extensive quote that follows.

Stowe Boyd wrote in his insightful article
"Are You Ready for Social Software?" published in Darwin Magazine:

Social software allows us to create new social groupings and then new sorts of social conventions arise. ... And this new software will support David Weinberger's notion of enabling groups to form and self-organize rather than have structure or organization imposed.... Social software reflects the "juice" that arises from people's personal interactions. It's not about control, it's about co-evolution: people in personal contact, interacting towards their own ends, influencing each other. But there isn't a single clearly defined project, per se.

There might be not in the early stages of emergent group-formation processes but having no clearly defined project is neither a criteria of social software, nor of the many well-defined social, business, knowledge, and technology innovation initiatives, that it can enable.

Using social software, one can develop new types of enterprise project that scale well up and down. It's true that the features of many tools in the current crop of social sofware are optimized for personal publishing and supporting spontaneous group formation. On that fondation, however, new social software features and tools can be easily developed for enabling coherent action to produce results that the team, the community or the organization needs and wants.

Providing some interesting insights in his project-blogging experience, Erik van Bekkum writes:

The blog is about conversation and not about project-related issues (tasks, co-authoring of documents). We had this right from the start, but the limitations of what the blog is good for comes strongly forward as the need to do these project-related issues, arises... Even just weeks into the experiment with the p-blog, the venture has proven its value next to the other tools (community, project management software, email etc) because it has distinctive advantages that allows the project blog potentially to unite (glue) all the other tools together.

If “innovation is the organizational equivalent of evolution” The Business of Innovation, by Bean & Radford, then we can expect that it will use evolution's dual engine, differentiation and integration, as its drivers. Here's how: