Phase-Wise Risks in OSS Projects While the advantages of Open Source are many, unrealistic expectations, ignoring important lessons in project management as well as limitations of the model may make some otherwise viable Open Source projects an interesting footnote in the overall history of Computing in times to come. Proliferation and availability of Open Source brings up different challenges in Analysing, Designing, Integration and Implementing Software based on Open Source, which must be carefully understood and handled to ensure that the project succeeds. A lot of information is available about the advantages and consequent risks of Open Source but little information exists about the phases in a software lifecycle where these risks are more likely to occur. Mitigation requires an understanding of the phases in which these risks are most prevalent and, thereafter, creating a methodology of best practices that allow repeated project successes that cover most scenarios of Open Source Usage. 1
About the Author Rakhi Gupta Rakhi Gupta is currently leading TCS Open Source & Linux Practice. She has over 14 years of IT experience, out of which last 8 years she has been architecting, designing and developing J2EE applications. She has also executed several J2EE Consulting Assignments. Additionally she has led enterprise migrations of Web and System Applications to the Linux platform. 1
Table of Contents 1. Challenges in the Analysis Phase 3 2. Challenges in the Architecture & Design Phase 5 3. Challenges in the Implementation 6 4. Challenges in the Integration Phase 6 2
In recent years, Open Source has received an increasingly wider acceptance throughout organizations. IT organizations adopt Open Source under different scenarios: Substituting a COTS (Commercial Off The Shelf) product by an Open Source Product due to the high cost involved with forced license upgrades and avoidance of vendor lock in Adopting an Open Source Product at a strategic policy level A bigger wave of adoption is proceeding at a different level within an organization that is dramatically affecting the way we develop software and software development practices. This is occurring at the developer level. From a developer s perspective, Open Source is a combination of two important properties: Visible source code Right to make unencumbered derivatives The developer experiences the following advantages: Shorter development cycle Better quality code when compared with bespoke development Best of breed software thereby avoiding reinventing the wheels Adoption of Open Source comes with its associated risks and affects the traditional methods we use in software development. To gain a deeper understanding of the risks associated with Software Development refer to How is Open Source affecting Software Development? by Diomidis Spinellis, Athens University of Economics and Business and Clemens Szyperski, Microsoft Research (Published by the IEEE Computer Society 0740-7459, Jan/Feb 2004). The Open Source movement performed a vital role in software development at the end of the 20th century and promises to continue to be an important centre for creativity in the next century. However, despite the technical skill and imagination of the members of the Open Source community, there are limitations to the Open Source model that should be carefully studied and compensated for. These limitations correlate to the human characteristics that make science, in general, and applied science, in particular, diffi cult activities. The paper by Nikolai Bezroukov on Open Source Software Development as Special Type of Academic Research stresses the advantage of OSS over commercial development - the inherent possibility of creating simpler products that are superior to commercial products in terms of functionality and user interface. For details refer to http://www.fi rstmonday.org/issues/issue4_10/bezroukov/index.html#author. While the advantages of Open Source are many, unrealistic expectations, ignoring important lessons in project management as well as limitations of the model may make some otherwise viable Open Source projects an interesting footnote in the overall history of Computing in times to come. Proliferation and availability of Open Source brings up different challenges in Analysing, Designing, Integration and Implementing Software based on Open Source, which must be carefully understood and handled to ensure that the project succeeds. A lot of information is available about the advantages and consequent risks of Open Source but little information exists about the phases in a software lifecycle where these risks are more likely to occur. While a lot has been spoken about the advantages and consequent risks of Open Source, little information exists about the phases in a software lifecycle where these risks are more likely to occur. Mitigation requires an understanding of the phases in which these risks are most prevalent and, thereafter, creating a methodology of best practices that allow repeated project successes that cover most scenarios of Open Source Usage. Below is a summary of the kind of challenges that are generally encountered during different phases of an Open Source Project. It is based on our experience of executing Open Source Projects and deploying reusable components in over 150+ projects. 3
Challenges in the Analysis Phase Appropriate Choice Inadequate Documentation The Open Source software has proliferated to a staggering 30,000 projects being registered on http://freashmeat.net and another 70,000 being registered on http:// sourceforge.net. This makes it complicated to select the correct fi t, thus making the Correct Choice of an Open Source S/W a challenge during this phase. It works very well for large projects but there are lots of smaller projects with unresolved defects waiting to be abandoned. Without a crystal ball, it is diffi cult to tell whether a particular Open Source project is going to be high-risk. Other issues include licensing issues that drive the correct choice. Most contributions take place through the Open Source community of developers. This results in less motivation to produce good documentation beyond coding. Developers have never been known to produce good User Manuals. The lack of User Level documentation in most Open Source products makes it diffi cult to perform a technical feasibility that evaluates one Open Source Product over another. Analysts often rely on third party information from websites and other sources where the information is usually not up to date. The other option is to consult the Gartner / Forrestor Magic Quadrant that recommends one software over another. However, any software is best applied depending on the requirements. Hence these sources are often inadequate. Therefore, another challenge during this phase is the Lack of good scenariobased user documentation or outdated documentation. After the success of JBoss and MySQL, more companies are realizing the advantages of an Open Source based business model, mainly selling Services instead of Licenses. Sometimes, although an entire code may be donated by these companies, there may be limited supporting documentation, thus increasing the dependency on IT organizations considering Open Source software to rely on the services of these companies. While some Open Source companies have mature support models, others do not. Appropriate Support Mechanism One of the key challenges in adopting an Open Source are Understanding the mechanism required to support the S/W. The above statements regarding a different set of challenges with Open Source software does not imply that the quality of commercial support is good. Nothing is further from the truth. Essentially, the situation for commercial software is similar to the Open Source support model. The argument can be made stronger because if the outsourcing of technical support is viewed as a progressive business decision, then Open Source defi nitely has an advantage. 4
For commercial software, the vendor usually supplies a feature list with a comparison of the competing products. This is not true for Open Source software that typically requires the analyst to be oriented towards analysing differently for an OSS. Correct Methodology Analyze OSS Trends Often the analysis is based on different sets of activities that are not anticipated in advance thereby leading to missed deadlines or compromise in the quality of the selection process, resulting in disastrous consequences. An organization level challenge is Lack of OSS oriented analysis Methodology. New versions of Open Source Products are evolving rapidly. Any analysis written about an Open Source feature product 3 months ago will be fairly out dated. An organization challenge lies in the Analyst team educated and up to date on OSS. Challenges in the Architecture and Design Phase Challenges in the Architecture and Design Phase are largely based on the Quality of the OSS interfaces and the architect s ability to leverage them effectively. An Open Source generally follows standards that allow building of extendable interfaces. Hence Quality of the OSS is usually a minor issue. Correct Architecture Our experience shows that architects tend to suggest designs that require OSS to be modifi ed, such as modifi cations of struts framework etc. There is a tendency to modify OSS because of the availability of source code, which creates a precarious situation. Upgrades in OSS are then no longer compatible with the internal version of this software and the project soon fails in its original mission of leveraging the OSS community for bug fi xes and enhancements to the OSS software that it originally adopted. Estimation Procedure The challenge in this phase stems from the Incorrect Architecture Practices around Open Source. With the availability of Open Source Frameworks, plug-and-play components, and short development and delivery timelines, designers increasingly leverage these while designing the overall system and may fail to add estimates related to usage of these components, including efforts required to test the overall integration with the interfaces of this software. The challenge in this phase stems from Understanding the effort required to integrate different interfaces with Open Source Components and estimate the efforts accurately. This is also applicable when estimating for proposals where Open Source Components are part of the framework. 5
Challenges in the Implementation Point 1 under Challenges in Architecture and Design identifi es the risk in OSS Modifi cations. Project Management Process However, this does not imply that OSS code must not be modifi ed, as this would defeat the very way OSS is viewed. In case of defects, users can fi x these without impacting delivery deadlines that would normally need to be compromised in commercial software. However, project management practices and processes should ensure documentation around these fi xes and contribution back to the OSS community, in order for these defects to be available in the next upgrade and also for review to impact modifi cation to the code. The challenge in this phase stems from Managing modifications to Open Source Code. Challenges in the Integration Phase Inadequate Integration Scenarios Most Open Source projects have been known to follow Open Standards in the industry. Issues, if any, abound when integrating with commercial products that have intentionally been made proprietary. However, cases or detailed examples that demonstrate how this integration was achieved may not be available, due to the very nature of these products being Open Source. There is no mechanism to track the usage of OSS. Commercial Organizations that adopt Open Source software in the enterprise are not motivated to share these cases. The challenge in this phase of the project may stem from Lack of scenarios and specific instances of problems and solutions. TCS Open Source & Linux Practice can help organizations to make the transformation to Open Source in a safe, cost-effective and smooth manner through our OSS Project Management Methodology, Tools and Assets along with TCS experience of having worked with over 500 global customers. 6
About Open Source & Linux Practice From understanding business pain areas, recommending and implementing solutions to providing support, the OSL practice at TCS helps enterprises to overcome the challenges moving to Open Source, achieve tangible results and optimize the Total Cost of Ownership (TCO). The OSL practice offers secure and scalable solutions, built around Linux & Open Source, that cover Application Development, Reengineering, Migration, Product Porting, Application Consolidation and Kernel Programming. About Tata Consultancy Services Tata Consultancy Services (TCS) is among the leading global information technology consulting, services and business process outsourcing organizations. Pioneer of the fl exible global delivery model for IT services that enables organizations to operate more effi ciently and produce more value, TCS focuses on delivering technology led business solutions to its international customers across varied industries. For more information contact Rakhi Gupta Tata Consultancy Services Ltd Akruti Business Port Road No 13, MIDC Andheri (East) Mumbai 400093, India Phone: +91-22-5660 6311 Fax: +91-22-5660 6855 Email: linux.practice@tcs.com Website : www.tcs.com All content / information present here is the exclusive property of Tata Consultancy Services Limited (TCS). The content / information contained here is correct at the time of publishing. No material from here may be copied, modifi ed, reproduced, republished, uploaded, transmitted, posted or distributed in any form without prior written permission from TCS. Unauthorized use of the content / information appearing here may violate copyright, trademark and other applicable laws, and could result in criminal or civil penalties. Copyright 2004-05 Tata Consultancy Services Limited 7