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.