I have blogged about  BOSS earlier. The issue is that C-DAC does not need a BOSS like fork (for lack of a better word let’s use fork) to monetise the development efforts that have gone into L10n. In fact a line item product oriented model like BOSS might just not cut much ice even though it has all the basic advantages of becoming the Operating System of choice for government departments. What could be more of robust a revenue stream is offering services (consultancy, deployment, support) around the corpus of work that C-DAC has under the aegis of L10n. However, to kickstart that effort, the primary objective would be to ensure that the components are widely used. To do this it would be required to do the follwoing:

• open up the body of work under appropriate OSI compliant licenses (GPL, LGPL whatever fits the bill and is approved)
• begin putting up the components through appropriate packaging mechanisms into upstream distributions viz, Fedora, Ubuntu, Debian, Mandriva etc

This would allow more and more users to be consumers of the products and thus enable putting in place a feedback loop. However, L10n components would lend themselves well to custom service consultancy eg creating assistive technology embedded OS or a digital library that integrates text to speech as a plugin/extension. These are the areas where C-DAC is best placed to leverage its experience and expertise. Extensive usage and distribution through upstream distributions also ensure that a completely integrated build process is put in place for accepting and implementing feature requests, patches among other things. The easiest way of doing this is putting in place the following:

• Repository of packages for various OS versions which can be accessed by the users (yum, apt-get etc)
• An issue tracker
• A mailing list
• A wiki

Working with upstream projects (GNOME, KDE, OpenOffice.org, Mozilla etc) and distributions mean that there is a healthy exchange of information and technical know-how sharing that would establish C-DAC as a true player in the FOSS space.

The core issue with doing an OS and then wrapping a business model around it is that of ensuring compatibility of kernel ABI and software API. Add to that the logistics of application certification and hardware certification and one has a full fledged task at hand. To top it all one needs to take the onus of supporting the binary/source collation for a fixed span of years. All this would be the task of a nicely populated engineering team. Services around existing competence provide a far more easier learning curve and productisation route.