Open Source software is often being referred to as commodity products. This is particularly true for OSS databases like MySQL or PostgreSQL. Developers of such systems can heavily make use of defined standards. In this case, it’s the various SQL standards. These standards define the general functionality set your product should have. They help you define the commodity features of your software.

The question is: where do you get your software requirements from if the OSS product you are developing cannot rely on any or only a few standards?

Let’s take a look at two other types of OSS products: Enterprise Content Management (ECM) and collaborative software. I used to work for an Open Source ECM vendor until recently and just started to work for a company offering Open Source collaborative software. Hence, I might be able to provide some useful information.

For ECM vendors, there exist a few standards in different areas of ECM. This is because ECM comprises a very broad set of functionality, e.g. content editing, workflow management, document management, accessibility, etc. Yet, these standards cover only a small fraction of what makes up a full-fledged ECM system. In fact, ECM is very much about customer-specific implementations and integration of legacy systems. It is a lot about experience, best practices.

Hence, a successful Open Source ECM project can define the set of commodity features by listening to its:

• customers
• partner companies
• developers and users community

These groups have different impact in different OSS ECM projects.

For example, eZ Publish is equally influenced by all three of them. At Alfresco, there is massive know-how of customer needs, simply because they have John Newton on board, co-founder of the very successful proprietary Documentum ECM. It will be interesting to see how eZ Publish and Alfresco will compete in the future. This will largely depend on how well the eZ Publish developers react upon market needs and on how fast Alfresco can grow its Open Source community. It’s actually not black and white, because customers can be a part of your developers community.

Before I talk about the interesting aspects of commodity features in collaborative software, one more note about highly standardized products: Of course, the MySQL developers need to also think of market needs. They first implemented the very basic features which made their RDBMS useful for simple, yet common scenarios in Web development. Standards do not free you from deciding which ones to implement first, but they help you to save time collecting all the potential features.

Now about collaborative software: Most development here is based on best practices. The interesting point is: these best practices are mostly already available in the Web. To be more precise: in the Web 2.0. At Mindquarry, we implement collaborative software which includes a Wiki, task and document manager (conversation tools for email and instant messaging coming soon).

Where do we get our basic ideas from? Well, from Wikipedia, Jabber, Bugzilla, etc. Mindquarry’s commodity features are out there in the Web and have been tested by a lot of users for several years. With Mindquarry, the trick is not about simply imitating an already existing and proven software infrastructure. It is about connecting the various bits and pieces of social software into one coherent infrastructure which you can use e.g. in your Intranet.

The point is: You can see the difference between the Web 1.0 and the Web 2.0 also in how OSS vendors define the commodity features of their products. An RDBMS is largely a Web 1.0 tool. It has at least one foot in the old days, when companies fought about software standards. Social or collaborative software is Web 2.0, you can find and influence its standards in the Web by providing efficient and rich user experience.

Of course, Web 2.0 standards rely on Web 1.0 standards, but the Web 2.0 is more about best practices and de facto standards on the user level compared to logical definitions of standards on the developers level. Again, the reality is not black and white. Take a look at MySQL’s and PostgreSQL’s ANSI92 SQL-defying LIMIT clause. It’s a best practice approach and shows that OSS developers always listened to their developers community just like Web 2.0 developers today listen to their users.

Although semantics in content management are being discussed and marketed for a long time already and always make up for a cool topic at conferences, they are rarely being used in real life. It is already hard enough for CMS users to get the content right and it is even harder to put it in the right context of a metadata set (especially if it is a large controlled vocabulary). This is where corporate “librarians” come into place, who control the use of controlled metadata – but they cost money…

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.