The difference between the successful open source implementation, in which the value of open source is realized for a company, and the unsuccessful one, in which the struggle to use open source is not worth the effort, amounts to knowing your problem, knowing the software, and knowing yourself.
The key to a successful outcome in applying open source is a thorough understanding of answers to the following questions:
• What problem are you trying to solve?
• How would open source software help in providing the solution?
• Does any open source software provide all or part of the solution?
• How can the maturity and stability of relevant open source software be determined?
• What skills are required to install, configure, customize, integrate, operate, and maintain the open source software?
• Does your organization have the needed skills? If not, how can they be acquired and institutionalized?
• In which cases does the value provided by the open source software exceed the cost of using and maintaining it, compared with other solutions?
An IT department that intends to adopt open source must have not only the resources to do so, but also a belief in skills building and an inclination to take increased responsibility for its IT infrastructure. We have analyzed the nature of open source and have listed three different models that can help companies evaluate the vast world of open source in a manner that is consistent and enables them to understand their own capabilities.
The models are:
1. Open Source Maturity Model: A set of questions that help determine the stability and maturity of an open source project, the responsibilities involved in using a particular piece of open source, and the skills needed to manage those risks (http://www.navicasoft.com/pages/osmmoverview.htm)
2. Open Source Skills and Risk Model: A set of questions that help determine the ability of an organization to handle various risks and the tolerance of risk for a specific project (See Open Source for the Enterprise By Dan Woods and Gautam Guliani – From which much of this article is borrowed)
3. Software Cost and Risk Model: A set of questions that help determine the total costs and risks of using open source as a solution for a project (http://sunset.usc.edu/csse/research/COCOMOII/cocomo_main.html)
Sunday, November 23, 2008
Monday, October 13, 2008
Open Source Software… Reality versus Myth
Recently, I have been working a couple of projects that have pitted commercial software against Open Source Software (OSS) during an evaluation phase to decide which to use in an enterprise CRM application. Initially, the commercial software won because of reluctance to change the selection process, misunderstanding of the real completeness of a COTS product (most COTS products require some degree of customization – the amount depends on the enterprise architecture and the complexity of the API), an over reliance on the face value of information provided during the presales phase of acquisition, and finally, the focus of the Open Source developers to provide an engineering framework and not a finished product (Although this is changing as more as more OSS developers recognize the commercial value of their product e.g., MySQL, SugarCRM, and Talend).
The adoption of OSS in the government is gaining momentum. OSS is reaching significant penetration well beyond its traditional IT infrastructure domain and is moving into applications, business intelligence and customer relationship management (CRM). Drivers of OSS adoption are also changing, witnessing increasing user maturity. The lower cost and local economic development benefits that drove early adopters have been replaced by total cost of ownership (TCO) considerations and the desire to overcome procurement complexity.
Currently, there is little expectation that open source will really free users from vendor dependence. However, an important aspect is the emergence of collaborative development efforts between agencies that use an open-source development process. The other side of the coin is; have you ever acquired a COTS product for an enterprise application that did not require engineering or significant “customized development”? Even such stalwarts as Microsoft are designing there signature products (such as Office) as platforms capable of being engineered, configured, and developed into enterprise applications.
FYI…. The commercial product first chosen, had to be abandoned due to cost and non-adaptability to the overall architecture…
The adoption of OSS in the government is gaining momentum. OSS is reaching significant penetration well beyond its traditional IT infrastructure domain and is moving into applications, business intelligence and customer relationship management (CRM). Drivers of OSS adoption are also changing, witnessing increasing user maturity. The lower cost and local economic development benefits that drove early adopters have been replaced by total cost of ownership (TCO) considerations and the desire to overcome procurement complexity.
Currently, there is little expectation that open source will really free users from vendor dependence. However, an important aspect is the emergence of collaborative development efforts between agencies that use an open-source development process. The other side of the coin is; have you ever acquired a COTS product for an enterprise application that did not require engineering or significant “customized development”? Even such stalwarts as Microsoft are designing there signature products (such as Office) as platforms capable of being engineered, configured, and developed into enterprise applications.
FYI…. The commercial product first chosen, had to be abandoned due to cost and non-adaptability to the overall architecture…
Tuesday, June 17, 2008
Open Source Ponderers, Ponder No More
Now that you feel fairly comfortable with your understanding of various Open Source licensing models – not sure which one is the best but you do know the differences… What Now? This will depend on a number of interrelated things - The capabilities of your company (which is closely associated with the “entrepreneurial model” of your company) and the maturity of the open source software. Are you a small or medium size company with an “early adopter” or “pragmatic” attitude? Are you a government agency – Federal, State or Local? Are you willing to internally “productize” an open source application? Do you have the programmers and testers to undertake such an endeavor? Should you outsource? Your next steps and decisions will be probably determined by how you answer these questions.
For example, if I am a small business or local government entity, I would probably want a “COTS” product (or at least one that is considered mature) because I have no interest in redistributing it (additionally, this makes my licensing choice a little easier.). I now must make a choice on Open Source application maturity. I also need to decide if I customize and integrate the chosen application with my internal resources or partner with an innovative company that focuses on Open Source integration within the enterprise. What would you do?
Your input is important because there is, understandably, a plethora of Open Source documentation written from the engineering aspect or from the entrepreneurial view point. But it is equally important that discussion from the “Business Person” requirement and concerns be heard….
Stay tuned, for discussions on “early adopters” versus “pragmatist” business models and their use of Open Source…
For example, if I am a small business or local government entity, I would probably want a “COTS” product (or at least one that is considered mature) because I have no interest in redistributing it (additionally, this makes my licensing choice a little easier.). I now must make a choice on Open Source application maturity. I also need to decide if I customize and integrate the chosen application with my internal resources or partner with an innovative company that focuses on Open Source integration within the enterprise. What would you do?
Your input is important because there is, understandably, a plethora of Open Source documentation written from the engineering aspect or from the entrepreneurial view point. But it is equally important that discussion from the “Business Person” requirement and concerns be heard….
Stay tuned, for discussions on “early adopters” versus “pragmatist” business models and their use of Open Source…
Monday, May 19, 2008
What is Open Source software and just what does it mean for your business?
This is the first in a series of blogs by MAI personnel to stimulate discussions within the community about Open Source software and its future impact on your business. This blog is purely introductory and will be followed up by blogs which specifically address both technical and business issues.
What is Open Source software and just what does it mean for your business? First, Open Source software does not mean “public domain”. For software to be in the public domain, the author must disclaim the copyright in the code. Open Source authors retain their copyrights. The difference lies in what the copyright holders elect to do with their rights in the code.
It is important for a business to understand that open source is fundamentally grounded in intellectual property law. There are five basic rights in copyright: the right to perform, the right to display, the right to copy, the right to make derivative works and the right to distribute. All software licenses grant the first two. The most significant differences between open source and proprietary software are the rights under copyright that the licensor grants to the licensee and the use philosophy behind each. The proprietary licenses restrict the use of the software as much as possible while the open source licenses have the aim to encourage wide use. Additionally, do not confuse Open Source and not being commercial. Open Source software can be commercial and in our case the “Free” in “Free Software” equates to “Freedom of use” not price.
There were some exceptions in the early nineties when the larger commercial software companies allowed “restrictive” inroads into their applications through the use of “Macros” (this practice quickly dried up once the larger firms saw this as a threat). This practice continues through the use of proprietary code such as (Application Programming Interfaces (APIs). However, businesses must carefully examine their licenses if they want to redistribute the modified code.
There are several good sources on Open Source licensing. One is “Understanding Open Source and Free Software Licensing” by Andrew M. St Laurent and another is titled “Succeeding with Open Source” by Bernard Golden. The knowledge of the fundamentals of intellectual property (as it pertains to software) helps in understanding what open source means to the several classes of users: (1) Small and medium-size businesses; (2) Enterprise customers; (3) Original equipment manufacturers (OEM); (4) Independent software vendors (ISV); and (5) Educational software and schools. Each of these categories has its unique requirements and issues which must be managed. Although having varying degrees of complexity, depending on your category, these issues are manageable. This is witnessed by the entrance of the major commercial vendors’ (Sun, Oracle, etc…) entrance into the Open Source arena at various levels.
Stay tuned….
What is Open Source software and just what does it mean for your business? First, Open Source software does not mean “public domain”. For software to be in the public domain, the author must disclaim the copyright in the code. Open Source authors retain their copyrights. The difference lies in what the copyright holders elect to do with their rights in the code.
It is important for a business to understand that open source is fundamentally grounded in intellectual property law. There are five basic rights in copyright: the right to perform, the right to display, the right to copy, the right to make derivative works and the right to distribute. All software licenses grant the first two. The most significant differences between open source and proprietary software are the rights under copyright that the licensor grants to the licensee and the use philosophy behind each. The proprietary licenses restrict the use of the software as much as possible while the open source licenses have the aim to encourage wide use. Additionally, do not confuse Open Source and not being commercial. Open Source software can be commercial and in our case the “Free” in “Free Software” equates to “Freedom of use” not price.
There were some exceptions in the early nineties when the larger commercial software companies allowed “restrictive” inroads into their applications through the use of “Macros” (this practice quickly dried up once the larger firms saw this as a threat). This practice continues through the use of proprietary code such as (Application Programming Interfaces (APIs). However, businesses must carefully examine their licenses if they want to redistribute the modified code.
There are several good sources on Open Source licensing. One is “Understanding Open Source and Free Software Licensing” by Andrew M. St Laurent and another is titled “Succeeding with Open Source” by Bernard Golden. The knowledge of the fundamentals of intellectual property (as it pertains to software) helps in understanding what open source means to the several classes of users: (1) Small and medium-size businesses; (2) Enterprise customers; (3) Original equipment manufacturers (OEM); (4) Independent software vendors (ISV); and (5) Educational software and schools. Each of these categories has its unique requirements and issues which must be managed. Although having varying degrees of complexity, depending on your category, these issues are manageable. This is witnessed by the entrance of the major commercial vendors’ (Sun, Oracle, etc…) entrance into the Open Source arena at various levels.
Stay tuned….
Subscribe to:
Posts (Atom)