Phase-Wise Risks in OSS Projects 1 TATA CONSULTANCY SERVICES
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.
Phase-Wise Risks in OSS Projects 1 TATA CONSULTANCY SERVICES
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.
Phase-Wise Risks in OSS Projects 2 TATA CONSULTANCY SERVICES
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
Phase-Wise Risks in OSS Projects 3 TATA CONSULTANCY SERVICES
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 levelA 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 derivativesThe developer experiences the following advantages:
●
Shorter development cycle●
Better quality code when compared with bespoke development●
Best of breed software thereby avoiding reinventing the wheelsAdoption 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.
Phase-Wise Risks in OSS Projects 4 TATA CONSULTANCY SERVICES
Challenges in the Analysis Phase
Appropriate Choice
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.
Inadequate Documentation
Most contributions take place through the Open Source community of develop-ers. This results in less motivation to produce good documentation beyond cod-ing.
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 op-tion 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
scenario-based user documentation or outdated documentation.
Appropriate Support Mechanism
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 increas-ing the dependency on IT organizations considerincreas-ing Open Source software to rely on the services of these companies. While some Open Source companies have mature support models, others do not.
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. Noth-ing 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 busi-ness decision, then Open Source defi nitely has an advantage.
Phase-Wise Risks in OSS Projects 5 TATA CONSULTANCY SERVICES
Correct Methodology
For commercial software, the vendor usually supplies a feature list with a com-parison 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.
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
Methodol-ogy.
Analyze OSS Trends
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
Correct Architecture
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 effec-tively. An Open Source generally follows standards that allow building of extend-able interfaces. Hence “Quality of the OSS” is usually a minor issue.
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 ten-dency 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.
The challenge in this phase stems from the Incorrect Architecture Practices
around Open Source.
Estimation Procedure
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 integra-tion 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
Phase-Wise Risks in OSS Projects 6 TATA CONSULTANCY SERVICES
Challenges in the Implementation
Project Management
Process
Point 1 under Challenges in Architecture and Design identifi es the risk in OSS Modifi cations.
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 with-out 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 modifi cations 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 mecha-nism 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 specifi c 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.
Phase-Wise Risks in OSS Projects 7 TATA CONSULTANCY SERVICES
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
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, Re-engineering, 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: [email protected] Website : www.tcs.com
