Open Source, R&D and People on Bench

R&D is a non-trivial activity. Most organisations have specialised groups working only in this area. The idea of allocating people to R&D with the proviso that the people may be pulled out any time with no notice seems absurd. That may be because of the way we are currently structured. Much like some of the banks whose branch organisation is unchanged but now give computerised passbooks. If the person responsible for printing passbooks is absent, the answer is 'sorry, can't be done, come back tomorrow'.

R&D is not merely creation of something new and different. There is also an applicative role. An organisation needs to know and understand how a new technology may be applied to a problem. Often crash programs or urgent recruitments need to be organised when a project requires the use of an unfamiliar technology or product. In this case, it is a project specific activity. On the other hand, if we recognise the possibility of some software being potentially useful and start exploring it, especially before it becomes successful, we would regard that as an R&D activity. This activity can be done in fits and starts provided there is some continuity and guidance.

An example may help. We got involved with a AJAX tool a few years ago. I had reservations about that product and would have preferred an open source alternative like Dojo. Dojo was new, with little documentation, and we knew nothing about it except my perception that it was the better option. The project time constraints did not leave any room for experimentation. We went with the required product and faced a lot of headache in trying to achieve the desired objectives, often winding up rewriting code using our own JavaScript routines. Had we written the additional code for Dojo, our name may have been in one of the source files.

An attraction of open source software is that we do not need to spend any money to buy a product. We do not have to restrict the number of products we can afford to explore. There will be no question of having to justify the cost of exploring a product. No one will say, 'By the way, what happened to the $1000 we had spent on X?”.

The missing piece in this environment is the manpower. We need to have a small core group which is passionate about open source and technically sound. The group need not have all the skills but must have the technical and people skills to guide and advise people on virtually any technology. The persons finishing a project are often bursting with ideas. There is often a feeling that we could have done better or there must be a better option. There could also be the category who have been bored stiff with the mundane work and would like a challenge. It is my belief that the people an organisation would like to retain will fall in one of these categories. All they need is for their energies to be channelled and their efforts recognised.

The next stage would be that these people could contribute to the projects. No ad or marketing rep can be as effective as contributed code to prove that an organisation can use and support a technology. But this is an incidental benefit.

Time is a consumable. Given the size of the Indian IT industry, it boggles my mind to think about the number of brain-hours that are, perhaps, not used every day. Can we afford to continue on this path?