DailyPost 1156
SOFTWARE – ORGANISED SOURCING VS CROWD-SOURCING
Software the ones being talked about is dynamic in nature, something which has to be developed as per the requirements of the customers, precise to his requirements and rolled out with perfect hand holding ending up in robust functioning. The IT/ Software products which are at the platform level is a different story altogether, let it be .Net or Python library or even a MS Office, the challenge is with the day to day problems which the individuals, enterprises and the government faces on a day to day level or needs a nature of collaboration which one company is not able to provide. The meaningless costing is another area of grave concern.
The black box way of functioning of the IT behemoths comes in way of creating codes which have to be democratic in nature; functionally and financially. Consortium through which integrated IT projects are pushed is not viable as it does not have the professional or the technical glue to stick. It’s just the profit sharing that brings diverse entities together. The Human Resource put on such projects are sourced as if it were low end plumbing or electricians work. Body Shopping. The different teams of the same company or companies working for the same SI on a project are like warring countries stitched by a Project Management Software. Only moolah mantra works. The AMC is another story. Is it worth the tonnes of effort to even get onboard in the complex / long procurement?
To outmatch it is an innovative mechanism, dynamic and real time. Still in nascent stage. Some issues liken the open source situation still plaguing it. Crowd sourcing of software. A nascent one with the capability to outlast all. The best possible way can be specific and precise Hackathons. Other ways can also be looked into. The basic kernel of the code is created by coders right in your presence under laboratory conditions, no manipulations whatsoever. World class experts of the class of IEEE can do the mentoring, jury, handholding, validation and then supervise, test and validate. Let’s give it chance and see how it fans out.
No software company will ever get a chance to do that for public domain problems. Neither will they know the coders specific for any domain leave aside the problem statement. Coders sit on the benches in IT companies. What a tragedy. It is thus a blind alley. The customer has no inkling of either the group of code developers or the even the kernel code or idea or design. The customer decides on the make believe bid submission, which is more of finance document, at best a document of intent. Why not a code processed by this route be treated as an OEM product and quality for necessary exemptions?
CODING IS FAR TOO IMPORTANT TO FOLLOW THE NORMAL PRODUCT ROUTE.
Sanjay Sahay