Snowman observed that when an organization considers implementing a commercial product, several groups get involved:...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
purchasing, legal, IT, finance and, perhaps, others. Their involvement enables an objective assessment of the terms and conditions of the software, including licensing -- so the organization knows what it's getting into.
With open source, all of that process can be short-circuited -- an individual engineer can commit the entire organization to a product just by downloading and integrating it into the system.
Snowman's point is that new conditions call for new procurement policies. She recommends that organizations establish an open source policy, publish it on an internal Web site, educate everyone to be aware of it and make the policy part of new employee orientation.
Although her recommendations are astute and useful, I realized they only get you part of the way home, however.
As an attorney, she understandably focuses on protecting her clients from legal liability. However, IT managers, project managers and project architects need to protect their organization from project risk. In the old way of doing things, during procurement other aspects of the product like its support, documentation and training could be assessed as well.
However, it's a new world today.
It is easy to bypass that assessment and planning process with open source. Just download and go -- only to find out later that important product elements like high-quality product documentation are missing. In a sense, open source makes it easy to reverse the traditional process. In the past, implementation came after assessment and planning; today, all too often, assessment and planning trail implementation. This poses real challenges for IT management, who must implement a process that lets them get ahead of the curve and ensure that all of their organization's needs may be met by a particular open source product.
To reduce this risk factor, we build our plans based on the Open Source Maturity Model. This model lets us assess the maturity of all critical product elements: software, support, documentation, training, integration with other products in the software stack and professional services. The output of the model enables us to develop project plans that address the requirements of all groups: development, operations, help desk and so on.
Notwithstanding its narrower focus, Snowman's recommendation is dead-on. New processes and policies are required for open source software. These processes will only work if you take the time to implement and adhere to them. Without a formal policy for open source usage, you will always be breathlessly running to catch up, worried that something is about to go wrong with your open source project.
Bernard Golden is CEO of Navica Inc., a systems integrator based in San Carlos, Calif. He is the author of Succeeding with Open Source (Addison-Wesley, August 2004) and the creator of the Open Source Maturity Model, a formalized method of locating, assessing and implementing open source software.