- The most dangerous jobs in technology
- Burning Man's open source cell phone system could save the world
- Only 5 (all women) of 135 pass Defcon social engineering test
- Fake antivirus software using ransom threats
- Cisco buys wireless smart grid company
Page 4 of 4
This "make it up as you go along" approach to managing open-source software concerns Douglas "Dougie" Stevenson. Enterprise Monitoring SME (subject-matter expert) at Savvis, a SaaS (software-as-a-service) vendor. Stevenson points out, "You put controls on what goes into production based upon how IT is going to support the services, what the application provides and what it does in your environment. Open source still needs to have user training/orientation, you still need to field issues with it and you still need to adapt it to your business needs."
So what does all this mean? Open-source management policies deal with the same issues over and over again, whether they're written up in a formal statement or (as is far more likely) is the collected wisdom of IT executives and staffers. These include:
Project stability: Can you trust the project to be there when you need it?
Project support: Can you get support when you need it?
Internal software management: Does your company know what open-source programs it's using? How it's developing and deploying them both in-house and to customers?
In general, companies do not appear to be handling these issues in a formal manner. Some of them, perhaps for the best, are incorporating open-source software management into general software management. As long as these companies avoid producing software for external use and avoid such traps as producing devices that include such programs, this approach should work.
In any case, CIOs should set up a framework to answer these common open-source concerns. That alone will take you a long way toward having an open-source policy that will work both for you and your company.
Comment