28 February 2009 - 4:19Open source domains

Open source started with the desire to create applications whose code could not be closed away from the general public and for a few decades followed this course. Operating systems, databases, application servers, frameworks, applications were written, had an OS license pasted on it and then released into the public. The only one exception to break away from this pattern is Spring Source, the company behind the Spring portfolio of products.

Spring source is an a-typical open-source company in the sense that they broke away from creating open source software and moving into creating open source domains. Initially they became known for their IoC container and a few libraries which solved various code issues (their JDBC libraries being one such example). Next, they added various features to the Spring container (proxy-based AOP, etc…) and added some more frameworks to their portfolio, such as Spring MVC, following the typical road of an OS company that senses industry-wide needs and addresses them by creating frameworks implementing those needs.
Lately, however, Spring Source has been diversifying into business domains: right now its product portfolio encompasses Spring Security (actually an old framework known as Acegi Security), Spring Batch, Spring Integration, etc… It is a pretty interesting development and, as far as I know, it is singular in the OS space: we have an OS company that senses domains that are needed across the IT industry, pools together domain experts and goes on to deliver a framework that covers the main concepts of the domain and is sufficiently flexible to allow for covering corner-cases easily.

One interesting point about OS domains is that the company that provides a framework which implements such a domain pretty much needs to acquire a significant marketshare and be guaranteed not to lose that marketshare and actually move to a monopolistic position as long as it delivers a good implementation of the domain. The reason for that is a domain is pretty much a form of knowledge and implementing a domain is essentially translating this knowledge into a particular programming language. If the knowledge has been translated into a programming language successfully (i.e. when the domain has been implemented robustly) there is no need for a competing implementation, because this competing implementation would simply re-translate what was previously translated, which is pointless (the end result is the same - a new translation of the same concepts).
Another interesting point is that the company servicing the OS domain will probably derive revenues from domain knowledge rather than from the framework/application implementing that domain, the support for the framework implementing a domain is actually a proxy for domain knowledge (people buying support for the framework will buy it for understanding the domain better and for using the framework better within the domain). 

If I were to say what qualities are necessary for a domain to become an OS domain I woud point out that such a domain needs to be quite static, it has to be mature enough and it needs to be in great demand, it has to cut across the whole IT industry.
If I were to point a domain which is ripe for becoming an OS domain I would say that partitioning an application to run across a large number of nodes will probably become a good candidate for an OS domain as the number of applications which need to scale out massively will increase.