There are two different sets of questions, depending on your background:

• IT Executives of CMS Vendors
• IT Executives of CMS End User Companies

Thanks for participating in the survey and please spread the word!

IKS is an EU-funded project with an overall budget of 8.5 million Euros. The first workshop back in May saw two dozen of bright Open Source CMS minds discussing a semantic stack in general. This time, it will also make sense for non-CMS-related Open Source projects and vendors to join.

There will be interesting presentations from some key figures at the second workshop in Rome, such as Peter Mika of Yahoo! Research talking about “The Role of Semantics in Search”.

If you’re up to joining the Open Source Web 3.0 train, then hurry up, because the October 22nd deadline for registering for the 2nd IKS workshop on semantic search is approaching quickly. See you there!

IKS is funded with 6.5 million Euros by the European Union and 2 million Euros are being invested by the consortium partners which makes up for an overall budget of 8.5 millions. The project will run for 4 years.

Financial support is available for 50 yet to be selected companies/organizations who agree to evaluate the IKS software stack as early adopters as well as 100 individuals who are members of a related FOSS project and who would like to actively engage in IKS project development. The budget for contributors to IKS is meant to alleviate the entry hurdles, e.g. for travel and accommodation for attending the IKS workshop end of May.

The premier focus of IKS is on FOSS content management systems and how they can make use of the to-be-developed IKS technology to let content objects behave the way they are supposed to across varying applications. Additionally, IKS also aims at cooperating with FOSS projects helping to implement semantics-aware software.

Wernher Behrendt, one of the initiators of IKS, exemplifies the project’s vision as follows:

Think of a task that has been defined in a project management software. Ideally, the project management software allows you to edit the task as you would expect it, for example, you can extend the ending date in case the work will take longer. Now, what happens if you want to transfer your work plan to the Web content management system that powers your Web site to display it to the public?

You will most likely create a screenshot of the work plan in the project management software, upload the screenshot in your WCMS and include it on a Web page. In between, you have lost all information about what a task is and how another application should treat it in case you want to edit it within the imported work plan.

This is where IKS comes to the rescue, because its software stack will not only provide a layer that takes care of metadata information (e.g. Ontologies, RDF, …), but will also be able to deal with information on how to process a content object across different applications.

If you’d like to join, IKS provides further information on its Web site and how to get in contact with them. Contribute to IKS as a…

• CMS vendor
• CMS end user
• Open Source developer
• CMS consultant, regional technology transfer organization, anyone else

InitMarketing

It currently includes 122 events in 17 countries taking place in 2009. 43 of them in Germany, 69 in USA. We use this calendar when planing events for our customers, thus we’ll regularly update it. Please let us know of any events which are not on our radar yet by commenting to my blog or commenting at the bottom of the events page.

The confusion – that Open Source is based on altruism – is a dreadful mistake. Speakers who argue that it happens due to the unselfish concern of developers for others, are simply unable to understand what is happening.

Those who say Open Source is altruism think of knowledge as a scarce resource, that only altruistic persons would share. The opposite is true: knowledge is an abundant good. For “trading” it, you get attention, trust, authority, etc. – all the things that help you to further develop your expertise and be successful.

As long as you don’t understand that point, you won’t understand the knowledge economy of Open Source. To extend Wheeler’s statement: Open Source is commercial when it comes to making money as well as “buying” knowledge with knowledge. This has nothing to do with altruism.

That chain leads from “raw material” such as emails to a blog entry that a staff member writes about a solution found in an email discussion. Another employee or community member might write an article based on that blog post and from several similar articles you could make a book.

In short: email -> blog -> article -> book.

A book is on the one side something like a high-end knowledge product. On the other side, it helps others to learn about your products and to innovate. That would be an ideal knowledge life cycle.

Open Source companies need to take into account the tight relationship they have with the community. The borders between those groups blur and eventually corporate knowledge management also needs to focus on the community.

In fact, the production of knowledge products by Open Source companies will work quite similar to how Open Source code is being created. That means, by listening to your community, you will understand what kind of knowledge products aka type of information they need most. This will help you to avoid wrong investments in the creation of knowledge products.

Theresa Regli, principal with CMS Watch, published the article Human Touch, discussing today’s problems and solutions to motivate users of content management systems to annotate/tag/classify/etc. information with metadata. The currently preferred solution for the taxonomy dilemma is group-dynamic annotation (folksonomy), as the article states:

�??The best motivation for tagging is almost instantaneous feedback,�?� adds Busch. �??Things like Flickr, del.icio.us, and Technorati�??the key to those is the instantaneous feedback�??the alerts, the feeds, the group tagging. That�??s why people get into it and get excited about it.�?�

It will be interesting to see, how large businesses and SMEs will adopt that strategy. They are not likely to communicate with the outside world to establish a swarm-intelligent taxonomy. Large enterprises might set up their own tagging infrastructure, while SMEs fall back to existing vocabularies, but don’t share the tagged information externally.

Additionally, there are different levels of confidentiality concerning corporate information: Some of it is for all employees, other only for the top management, certain teams, etc. This fragments the group-dynamics due to confidentiality gaps especially in large enterprises, who could actually profit from a broad collective intelligence when it comes to a high quality folksonomy.

The big hope concerning Social Tagging For The Enterprise is of course to optimize knowledge flows and to save money. Yet, it needs to be testified whether collaborative annotation can really live up to its expectations in firms. The larger and more complex the corporate environment, the more likely you will need dedicated and professional metadata reviewers. It would be an illusion for large enterprises that folksonomy translates into knowledge-management-for-free. SMEs on the other side could suffer from limited resources to ever have a useful folksonomy at hand. They might be blinded by a massive tag cloud.

On the other side, as with all data that becomes part of the public domain: in the end, all sorts of enterprises and organizations could profit from social annotation, simply because experiences are already being made by many people. Related Open Source software and publicly showcased approaches are being constantly refined, existing tag collections are readily available to be directly included or used for inspiration. That will in sum lift up all enterprises when it comes to how effectively they make use of their organizational knowledge with the help of a tagging staff.

The question is not, how much enterprises will profit from folksonomies, the question is how effectively they will make use of it by combining social software with a corporate culture where most of the employees are happy to share what they know by providing hints what their knowledge means to colleagues.

A Chief Knowledge Officer is an organizational leader, responsible for ensuring that the organization maximizes the value it achieves through “knowledge”. [...] CKO responsibilities include such things as (1) developing an overall framework that guides knowledge management, (2) actively promoting the knowledge agenda within and beyond the company, (3) overseeing the development of the knowledge infrastructure, and (4) facilitating connections, coordination and communications.

That’s quite a nice description. One special thing about eZ systems is, that it is an Open Source company, thus the borders between internal and external communication often do not exist. In fact, an Open Source company is just as much about an open communication as it is about open software.

This is actually the part I am most excited about: to explore the potentials of open knowledge management, which includes the eZ systems team just as much as the developers community, the partners, etc. In an Open Source ecosystem, knowledge management is very much a joint effort of all actors involved and can only follow a bottom-up approach.

With the CKO role, eZ systems is the only Open Source company I know of with a dedicated role for managing its knowledge and that of the whole ecosystem. It shows that eZ systems is serious about its slogan “Share your Information”.

If this all sounds too abstract to you, stay tuned, as I plan to write about concrete KM projects and their results in my Weblog.

Serving the Mass Market

First of all, when talking about a commodity, I think of a product for the mass market. Many software applications have indeed become commodity products, e.g. a well-known operating system. In respect to Open Source software, being a
commodity has been identified as one of three key factors for success.

Quantity or Quality

Software is a knowledge product, when you compare it to industrial commodities, e.g. doormats, is there any difference? The answer is that industrial commodities are physical goods and each new product will take resources to manufacture it. Hence, you always encounter the trade-off between quality and quantity with industrial commodities.

Quite different with software, as this is a virtual product. Software can be copied for almost zero cost, but developing it is a complex and time-consuming task. There’s actually no trade-off between quality and quantity when talking of software commodities and physical goods. The only trade-off concerning knowledge commodities like software is between quality and time.

Copy/Time vs. Optimization/Time

Concerning industrial commodities, there’s a copy-per-time ratio, because the amount of products you can create, is limited by the time it takes to manufacture each product. On the other hand, knowledge commodities have an optimization-per-time ratio. There, you don’t have to invest time to create copies of the product, instead, you can invest your time into making the product better.

Optimizing the Optimization

Due to the optimization-per-time ratio of knowledge commodities, the key to success for a software company is that it optimizes its optimization processes. Knowledge companies have the fear to become mentally lame and not agile enough to compete. In other words: they should take care of their potential to optimize the optimization-per-time ratio.

One measurable example would be more bug fixes in shorter time, but still, this would not say anything about the quality of the patches. High quality expectations need to be a natural part of every knowledge company and its organizational form and company culture needs to support every single employee to live up to these expectations.

Ecosystem of Optimization

Open Source companies and projects provide an open ecosystem to gain maximum optimization of their software commodity products, e.g. by bug fixes and new features contributed by third parties. In proprietary companies, the ecosystem is rather closed and they need to rely on internal resources mostly.

Now, the next question would be, whether the open or the closed ecosystem of optimization is more efficient and competitive? Let’s deal with it in another blog – this one is already long enough.

If the outcome of all the discussion is that we agree on actions and I am the one in charge to do and/or manage the implementation, then I simply group all emails in my Thunderbird inbox by the subject of the mailinglist discussion. This allows me to extract tasks from the discussions, which I store in the task tracker.

Now, I can keep track of every single issue by assigning each task to a category, giving it a priority, defining a due date, etc. Certain tasks might require some more discussion or consulting with other team members, which is done in the relevant mailinglists again – and this is where the process starts again.

In a nutshell, the approach is:

1. Post an idea to the mailinglist.
2. Keep the discussion going until a decision for or against actions has been reached.
3. Extract tasks from the discussion.
4. Discuss single tasks in the mailinglist if necessary (go to 1.)

Communication Skills

This seems to be quite simple and obvious, but in fact requires some sensitivity. The inital idea you post to the mailinglist, or the single task you want to discuss in more details, needs to be focused – otherwise you will end up with broad discussions that have no or too many results.

Then again, even a focused initial posting can lead to general questions. Either you moderate the discussion to become focused again, or you take up the raised issues because they might be critical, e.g. being a showstopper, or unclear responsibilities, or being of higher strategic importance.

As you are the one who raised the initial issue in the mailinglist, you should always feel responsible for the thread to be of value to others. Then you will automatically only post stuff which is important. On the other side, you can well invite others to help you become clear about certain problems if you got stuck.

Exchange of Information

Mailinglists are an excellent mean to distribute information within a team or even accross teams. In an ideal situation, they help to find solutions and make decisions jointly, something that fosters the support by each team member to actually implement his tasks.

The problem lies in a potential information overload, that too many people discuss too many issues in a mailinglist. The best way to avoid the overload is to apply the above mentioned communication skills.

As “overload” is also a subjective impression, it can help to learn how to quickly scan emails without reading them in details, to first spot whether they are actually of interest to me. The more subscribers are able to apply this skill, the more quality the conversation will get, as irrelevant postings will not get attention.

If in doubt, it is always better to have communication, even if too fuzzy and too much, instead of cutting it off. The question is how to canalize it in a productive way.

Other Channels

Of course, you can also apply the above said to other communication channels, e.g. forums or IRC chat. They all have their own characteristics though. A forum servers like a knowledge base automatically, similar to a mailinglist archive. Quite different compared to mailinglists, forums are not a push medium, but rather a pull medium, because you don’t get the information automatically to your email client’s inbox.

Open Company Culture

Using mailinglists as a part of project management requires an open company culture to be of benefit. This includes team members who are not afraid of telling their opinion with the risk to be challenged by others. In other words, they need to be adaptive.

In the end, being adaptive is the key of successful communication when implementing a project. Just remember that as a little baby, you were basically only able to screem. Today you can read (I asume so, because you read this blog) – and there’s always more room for the improvement of your communication skills. The main problem seems to be though, that most of us don’t remember the times when they were a baby and think that they’ve been born with ready-made communication skills