A STUDY ON THE CHOICE OF FREE & OPEN SOURCE SOFTWARE FOR GOVERNMENT SECTOR ENTERPRISE APPLICATIONS IN SRI LANKA
MASTER OF BUSINESS ADMINISTRATION IN INFORMATION TECHNOLOGY
K M S P Jayawardena Department of Computer Science & Engineering University of Moratuwa December 2008
i
A STUDY ON THE CHOICE OF FREE & OPEN SOURCE SOFTWARE FOR GOVERNMENT SECTOR ENTERPRISE APPLICATIONS IN SRI LANKA
By
K M S P Jayawardena
This Dissertation was submitted to the Department of Computer Science & Engineering of the University of Moratuwa in partial fulfillment of the requirement for the Degree of Master of Business Administration.
Department of Computer Science & Engineering University of Moratuwa December 2008
ii
DECLARATION “I certify that this thesis does not incorporate without acknowledgement, any material previously submitted for a degree or diploma in any university, to the best of my knowledge and believe it does not contain any material previously published, written or orally communicated by another person or myself except where due reference is made in the text. I also hereby give consent for my dissertation, if accepted, to be made available for photocopying and for interlibrary loans, and for the title and abstract to be made available to outside organizations”
……………………………
…………………………..
Signature of the Candidate
Date
K M S P Jayawardena
The above particulars are correct, to the best of my knowledge. …………………………….
…………………………..
Supervisor
Date
Prof. Gihan Dias
iii
ABSTRACT This document presents a study on the selection of software for government sector enterprise applications. Many factors could influence the choice of software in government sector enterprise applications. The research is based on the following problem: what factors influence the choice of software for government sector enterprise applications, in the Sri Lankan context.
Information systems (IS) projects in several selected government sector organizations have been studied in depth during the course of the research. Around 30% of the investigated government sector information systems projects have been found to have used FOSS. Several factors have been identified to have affected the choice of software for government sector enterprise IS. Out of these, technical compliance, cost, bidders/developers expertise and maintenance/support options were some of the most commonly indicated factors. Cost was highlighted as an important factor in a majority of the investigated IS. However, the analysis revealed that cost did not influence the choice between FOSS and proprietary software, when implementing the IS. This was quite unusual given the common perception that FOSS is used to lower costs. It was concluded from the analysis that certain other factors including bidders/developers expertise,
technical
compatibility
with
legacy
proprietary
systems
and
maintenance/support options override the cost factor, when selecting software.
Based on the analysis and conclusions, several recommendations have been made to leverage on the benefits of FOSS in government sector enterprise IS. These recommendations include ways to achieve cost advantages, especially in large scale replication. It is recommended to nurture a FOSS ecosystem and to develop internal FOSS expertise within government organizations, in order to leverage on the advantages of FOSS in government sector enterprise IS.
Keywords: Enterprise Software, Government, Free and Open Source Software, Software Adoption. iv
ACKNOWLEDGEMENT I would like to extend my heartfelt gratitude to my supervisor, Professor Gihan Dias for his invaluable guidance and constant encouragement. I would also like to thank Mrs Vishaka Nanayakkara and Dr Chandana Gamage for their guidance and advice.
This research would not have been possible if not for the sincere help of Mr. Wasantha Deshapriya , the staff at the ICT Agency and government organizations. I wish to thank them for spending their valuable time in order to make this research a success.
Finally I wish to thank my parents and family for their constant encouragement. I would especially like to thank my wife Nirasha, for bearing up with me and constantly encouraging me.
K M S P Jayawardena MBA/IT/07/9071
v
TABLE OF CONTENTS DECLARATION
iii
ABSTRACT
iv
ACKNOWLEDGEMENT
v
Chapter 1:
1
1.1
INTRODUCTION
Background of the study
1.1.1
1
Free and Open Source Software (FOSS)
1
1.2
The research problem
2
1.3
Research objectives
3
1.4
Significance of the study
3
1.5
Research methodology
3
1.6
Scope of the study
4
1.7
Data collection
4
1.8
Data analysis
4
1.9
Nature and form of results
4
1.10
Structure of this document
4
Chapter 2:
6
Success in Enterprise Systems
6
2.1
LITERATURE REVIEW
2.1.1
The DeLone and McLean Model
6
2.1.2
Enterprise Success Model
7
2.2
Use of FOSS in the Government Sector
9
2.2.1
Cost Savings
9
2.2.2
Security, stability and privacy
9
2.2.3
Independence
9
2.2.4
Helping domestic industries
9 vi
2.2.5 2.3
Innovation
10
Open Source Adoption
10
2.3.1
Policies
11
2.3.2
Choice set
12
2.3.3
Selection
12
2.3.4
Other Adoption factors
13
RESEARCH METHODOLOGY AND DESIGN
14
Chapter 3: 3.1
Scope of the research
14
3.2
Research strategy and approach
14
3.3
Interview Design
14
3.3.1
A general investigation
15
3.3.2
Technology and Components
15
3.3.3
Specification development and selection
15
3.3.4
Factors affecting the selection
15
3.3.5
Issues, improvements and FOSS
15
RESEARCH FINDINGS
17
Spread of the investigated projects
17
Chapter 4: 4.1 4.1.1
Implementation stage of the project
18
4.1.2
ICTA guided and non-ICTA projects
19
4.1.3
The use of FOSS/ Proprietary software in the project
19
4.1.4
Nature of Specifications Development and Implementation
20
4.2
Factor identification
Chapter 5:
21
ANALYSIS AND CONCLUSIONS
24
5.1
Technical compliance
25
5.2
Cost
26 vii
5.2.1
Total cost vs. the cost of the IS component
27
5.2.2
Compliance with existing technology
28
5.2.3
Use of unlicensed proprietary software
28
5.2.4
Conclusions
29
5.2.5
Methods of highlighting the cost as an important factor
29
5.3
Bidder/developer expertise
29
5.3.1
GIC Project
30
5.3.2
Internally developed system
31
5.3.3
Conclusions
31
5.4
Support and maintenance
32
5.4.1
Statistical perspective
32
5.4.2
A different scenario
33
5.4.3
Conclusion
33
5.5
Factor summary
33
5.6
Analysis
based
on
specification
development
methodology
and
implementation 34
5.6.1
ICTA/SAGE
35
5.6.2
External consultant
37
5.6.3
Developed in-house
37
5.6.4
PPP
38
5.6.5
Summary of analysis by specifications development and implementation 38
Chapter 6:
RECOMMENDATIONS
40
6.1
Recommendations on building expertise
40
6.2
Recommendations on developing internal expertise
40
6.2.1
Knowledge sharing
41 viii
6.3
Technical compatibility with legacy systems
41
6.4
Recommendations on developing specifications
41
6.5
Concluding remarks
42
REFERENCES
42
APPENDIX A - List of organizations
45
APPENDIX B - List of projects
46
APPENDIX C - Questionnaire
48
ix
LIST OF FIGURES Figure 1: Survey conducted by the CIO magazine (Orzech, D 2002)
2
Figure 2: The Updated D&M Model
7
Figure 3: The Enterprise Success Model
8
Figure 4: Open Source Adoption Model (Kwan and West 2005)
10
Figure 5: Implementation stage of investigated IS
18
Figure 6: Spread of ICTA and non-ICTA projects
19
Figure 7: The use of FOSS components in IS investigated
19
Figure 8: Projects by nature of specifications development
21
Figure 9: Spread of the identified factors among the investigated projects
24
Figure 10: Technology spread of IS that considered technical compliance as an influential factor
26
Figure 11: Technology spread of IS that considered Cost as an influential factor
26
Figure 12: Technology spread of IS that considered bidder/developer expertise as an influential factor
30
Figure 13: Technology spread of IS that considered support and maintenance as an influential factor
32
Figure 14: Factor summary
34
Figure 15: The spread of technology in ICTA/SAGE projects
35
Figure 16: The spread of technology in projects where external consultants were involved
37
Figure 17: The spread of technology in projects that were developed in-house
38
Figure 18: Summary of analysis by specifications development and implementation 39
x
LIST OF TABLES Table 1: List of organizations and organization codes ................................................ 46 Table 2: Investigated IS Projects ................................................................................. 47
xi
LIST OF ABBREVIATIONS CIO – Chief Innovation Officer CRM – Customer Relationship Management FOSS – Free and Open Source Software HRM – Human Resource Management ICTA – The ICT Agency of Sri Lanka IS – Information System LGN – Lanka Government Network MIS – Management Information System ODBC – Online Database Connection PPP – Private Public Partnerships SAGE – Software Architecture Group of Experts
xii
CHAPTER 1: INTRODUCTION 1.1 Background of the study Free and Open Source Software (FOSS) is claimed to have a unique blend of benefits that have aroused the interest of organizations across the world. Some of these benefits have been reported to be as follows. A Total Cost of Ownership (TCO) study conducted by the Robert Francis Group (Orzech 2002) reveals that the use of FOSS computer operating systems like GNU/Linux can lower TCO up to 40%. Further to this, Gartner has reported a cost reduction of 15% (Maguire 2003) when using FOSS Operating Systems as opposed to Windows XP, which is a proprietary Operating System. A study done by Merill Lynch (Lemos 2003), a major financial management company, has revealed that TCO reductions by the use of FOSS are not only due to software licensing costs but from personnel and hardware costs. A recent e-Primer of the United Nations Development Program (Wong 2004) mentions enhanced security and vendor independence as other benefits of the use of FOSS in government applications. 1.1.1 Free and Open Source Software (FOSS) According to the Free Software Foundation (2005), Free and Open Source Software are software that are licensed such that its human readable source code is freely available for implementers to study, change and improve its design. Research (Reddy and Evans, 2002) reveals that more than 48% of the government institutions in Chile use FOSS with at least another 11% planning to do so. Out of this 93% of the institutions use FOSS for server side applications. According to the findings of Chan (2007), several developing governments like Peru have attempted to adopt FOSS at a national level. A recent online survey done by the CIO magazine (Schindler 2008) during the period April 28, 2008 to May 2, 2008 shows that more than 50% of the participants are using FOSS. Another 10% of the participants are planning to use FOSS during the 1
next 12 months. Therefore there appears to be a growing interest in the use of FOSS across the world.
FOSS Usage No plans to use FOSS 37%
Currently Using 53%
Planning to use FOSS within the next 12 months 10%
Figure 1: Survey conducted by the CIO magazine (Schindler 2008)
1.2 The research problem Government sector Information Systems projects guided by the ICTA are a part of the e-Development initiative of Sri Lanka (e-Sri Lanka), which is funded primarily by the World Bank. The World Bank publication by Hanna (2006) describing the experiences of envisioning and designing of the Sri Lankan e-Development program highlights that it can benefit from the use of FOSS. Apart from this, the literature surveyed have highlighted how organizations could benefit from the use of FOSS. However, to realize the benefits of FOSS, decision makers should perceive it as a viable option. Hence it is important to identify what affects the choice of software at a strategic level. This leads us to the problem statement of this research.
2
“What factors influence the choice of software for government sector enterprise applications in Sri Lanka?”
1.3 Research objectives Based on the above problem statement, this research consists of the following objectives.
To identify factors that affects the adoption of Software in Sri Lankan government sector projects.
To identify what features are considered as important in large Information Systems, and how they relate to Open Source Software.
To develop suitable recommendations for the better selection of software in the Sri Lankan government sector.
1.4 Significance of the study The study identifies the factors that affect the adoption of software for enterprise applications. Moreover, it focuses on those factors that are peculiar to the government sector in Sri Lanka. It also identifies what aspects of ISs are taken in to account when different government sector institutions evaluate an IS. The study will help formulate polices that will aid government sector organizations to leverage on the benefits of FOSS as explained in section 2.
1.5 Research methodology The research methodology involved a rigorous study of selected government organizations as outlined in the scope of the study. The research was designed based on the findings of the literature study and the research objectives. Data collection was carried out based on this research design. The obtained data has been analyzed as explained in the analysis section.
3
1.6 Scope of the study The scope of the research is limited to government sector ISs. Government projects coordinated through the Information and Communication Agency (ICTA) of Sri Lanka and other selected government organizations have been taken as case studies.
1.7 Data collection The data was collected by interviewing staff at different levels in the selected organizations. This included personnel at a strategic level and heads of the IT/IS departments. In the case of ICTA guided projects the interviews consisted of the ICTA project managers and relevant external stakeholders.
1.8 Data analysis The data was comparatively analyzed on a case by case basis to identify common patterns and trends among the investigated organizations and projects.
1.9 Nature and form of results The results of the research are qualitative in nature. It is a comprehensive study of the factors that affect the adoption of FOSS in the Sri Lankan government sector organizations
for
enterprise
systems.
The
results
also
include
suitable
recommendations for capitalizing on the advantages of FOSS in the Sri Lankan government sector.
1.10 Structure of this document The remainder of this document is organized as follows.
Literature review This section reviews literature from related studies.
4
Research methodology and design This section describes how the research was designed.
Research findings This section presents the findings of the research.
Analysis and conclusions This section presents an analysis of the research findings followed by relevant conclusions.
Recommendations This section presents suitable recommendations on leveraging on the benefits of FOSS in government sector IS, based on the analysis and conclusions derived from the previous section.
5
CHAPTER 2: LITERATURE REVIEW This section elaborates on relevant information that was gathered from existing literature. The information gathered covers the success of enterprise systems, FOSS in the government sector and FOSS adoption models.
2.1 Success in Enterprise Systems Several models have been developed to assess the success of Enterprise Systems. The models explored during the literature review are as follows. 2.1.1 The DeLone and McLean Model The DeLone and McLean model (D & M Model) was first published in 1992 (DeLone and McLean 1992) based on theoretical and empirical research. The initial model measures IS success based on the following constructs/dimensions.
System Quality
Information Quality
Use
User Satisfaction
Individual Impact
Organizational Impact
The initial model has been further refined in the updated D&M Model (DeLone and McLean 2003). The updated model introduces a third dimension – “service quality”. It also combines individual and organization impacts as “net benefits”. Therefore, the updated model considers the success of the system based on the information quality, system quality and the service quality. The model strives to analyze the associations between these dimensions and the intention to use, the user satisfaction and net benefits. A pictorial representation of the updated D & M model is shown in the figure 2. 6
Figure 2: The Updated D&M Model
2.1.2 Enterprise Success Model The Enterprise System Success Model presented by Gable et al (2003) shows a temporal analysis of the success based on what is to date and what happens in the future. A pictorial representation of this Enterprise Success Model is given in figure 3. The model has the following four quadrants.
Individual impact
Organization impact
System quality
Information quality
These quadrants represent four distinct but related dimensions of enterprise system success. These measures represent a snapshot of the organizations experience of the enterprise system at a particular point in time. The impact dimensions assess the
7
benefits (or otherwise) that have followed from the system. The quality dimensions reflect the future potential.
This model deviates from the traditional D&M model (DeLone and McLean 2003) in the following ways.
It depicts a measurement model as opposed to a causal/process model of success
It omits the „use‟ construct
Satisfaction is considered to be an overall measure rather than as a dimension of success
Figure 3: The Enterprise Success Model
8
2.2 Use of FOSS in the Government Sector Government sector software applications require long term continuity and a lower total cost of ownership (TCO) while maintaining a high degree of quality and integrity. Mitch Stoltz (1999) mentions that governments can use open source as a vehicle for promoting economic development. Some of the benefits of the use of FOSS in the government sector have been identified by Reddy and Evans (2004) as follows. 2.2.1 Cost Savings Significant cost savings can be made due to the lack of expensive licensing fees in FOSS. 2.2.2 Security, stability and privacy As the source code is open for inspection, it is claimed that FOSS is more secure and stable. The German government was concerned that some versions of the proprietary Microsoft Windows operating system contained back doors designed to grant the US National Security Agency, access to user data. Based on this rationale, the government of Germany has adopted a strong FOSS policy (Reddy and Evans 2004). 2.2.3 Independence Proprietary software solutions often based on one or few software companies. Hence a government implementing such proprietary solutions will have to depend on those few companies for support and business continuity. Due to the open nature of FOSS, dependence on software companies is less (Reddy and Evans 2004). 2.2.4 Helping domestic industries The open nature of FOSS will help the domestic software industry to actively contribute in developing applications. This is important for the long term sustainability of government projects and in terms of national interests.
9
2.2.5 Innovation The open nature of FOSS helps innovation. This results in more advanced and efficient software which are released faster than proprietary software which have to adhere to conventional release cycles.
2.3 Open Source Adoption Kwan and West (2005) of the Silicon Valley Open Source Research Project, San JosĂŠ State University, have presented the following Conceptual Model for Enterprise Adoption of Open Source Software (Refer Figure 4).
Figure 4: Open Source Adoption Model (Kwan and West 2005)
The three phases of this adoption model are policies, choice set and selection. Each of these is explained below.
10
2.3.1 Policies According to Kwan and West (2005), a firm establishes a series of policies that guide its procurement decisions. These could be formal or informal policies. Most organizations have a pattern of attitudes and decisions that form a de facto policy on how open source software will be considered. The following four broad categories have been identified to influence the makeup of the policy. 2.3.1.1 Industry Context Different industries have different levels of the competitive intensity, profitability, buyer power and environmental shocks. Thus the industry context could lead to similar IT strategies across different firms in that industry. 2.3.1.2 Firm Context Although firms in the same industry may have a common context, different firms may have different levels of IT/IS intensity. Therefore, high IT/IS intensity firms would be more knowledgeable about IT/IS, and would spend more time evaluating new technologies. 2.3.1.3 Standards attitudes Firms have differing opinions about the choice provided by open standards as opposed to the tight integration provided by proprietary vendors. Differences in attitudes towards standards can influence the likelihood of adopting open systems. 2.3.1.4 Open source attitudes Attitudes towards open source can be expected to be roughly parallel to attitudes towards standards. Some organizations are favorable towards open source and others are antagonistic towards it, while still others could be agnostic towards the whole notion.
11
2.3.2 Choice set At this phase the firm identifies an acceptable set of alternatives that meet the minimum requirements. This is based on the available range of options. This is done at the first decision point (refer Figure 4). 2.3.3 Selection The final selection is made at the second decision point. This is based on the previously selected „choice setâ€&#x; of acceptable alternatives (refer Figure 4). According to Kwan and West (2005) the attributes of various products can be categorized as follows when analyzing the selection. 2.3.3.1 Features These are the attributes commonly used to measure what is new or valuable about a given technology. It is something vendors use to differentiate their products. 2.3.3.2 Risk This is often thought of in terms of reliability. It implies the comparative scarcity of crashes, failures, or data loss. Risk-lowering measures might also include efforts to mitigate the effect of inevitable if rare failures (such as redundant data or 7/24 support). Firms also consider the risks of their investments over time. This includes risks such as the risk that the technology may be orphaned by the vendor. 2.3.3.3 Cost Costs include both the initial purchase price, and the ongoing usage costs such as support contracts and upgrade fees. An attempt to calculate total cost of ownership would also include personnel cost, related equipment costs such as power, air conditioning, security, etc. The latter is particularly relevant for large data centers.
12
2.3.4 Other Adoption factors The following factors have been identified by Dedrik and West (2003) as open source adoption factors in their grounded theory based research.
Willingness to take risks on a new, unproven technology.
Need for organizational slack to evaluate the new technology and to selfsupport unsponsored technologies.
Tendency of open source software to be inexpensive if not free and the inherent „trialability‟ of “free” software distributed on the Internet.
Availability of external sources of support and expertise.
13
CHAPTER 3: RESEARCH METHODOLOGY AND DESIGN
The intention of the research was to investigate a selected set of government IS in considerable depth. Therefore a case study based approach was adopted. IS projects of selected government organizations have been studied on a case by case basis. Therefore the study is mostly qualitative in nature. The data collection was done through interviews. Staff at different levels of the organization has been interviewed as appropriate in order to obtain a more holistic perspective.
3.1 Scope of the research The research focuses on IS pertaining to a selected set of government organizations. The sample set consists of ICTA guided IS projects as well as non-ICTA IS projects in order to facilitate comparative analysis. The list of organizations and the IS projects included in the study are indicated in Appendix A and B.
3.2 Research strategy and approach A qualitative approach was selected for the study owing to the limited number of government sector enterprise IS projects. A multiple case study approach was selected as opposed to a single case study. As suggested by Yin (2003) the overall evidence from a multiple case study could be considered to be more compelling and robust, when it can be afforded to. Therefore, selected enterprise IS of selected government organizations were taken as case studies. The data collection was done using in-depth interviews. The interviews were recorded electronically with the prior permission of the interviewees for further analysis. Apart from this interviewees were have been contacted for clarifications during the analysis.
3.3 Interview Design The interviews were carried out based on a broad outline. The interviews investigate the source of the requirement specifications along with the nature of the technologies 14
and factors that influenced the IS solution. Issues and room for improvement in selected IS have also been investigated. The interview outline (Appendix C) covers the following aspects. 3.3.1 A general investigation The main projects, the project objectives and components were identified in this section. This is addressed in section 1 of the interview outline in Appendix C. 3.3.2 Technology and Components The software, hardware and middle ware components used for each project were identified. The use of proprietary and FOSS components were investigated and identified. This is addressed in section 2 of the interview outline in Appendix C. 3.3.3 Specification development and selection The nature of the specifications development for each IS was identified. This section investigates if specifications were developed internally, by an external consultant and in the case of ICTA guided projects, the involvement of a SAGE. Section 3 and 4 of the interview outline (Appendix C) cover these aspects. 3.3.4 Factors affecting the selection This section investigates the key factors affecting the selection of the IS system concerned. In the case of a procured solution the factors affecting the selection process were investigated. It was also investigated if the interviewees had any recommendations to improve the current selection process. If the IS was developed by internal staff, the reasons behind this decision was investigated. These are addressed in section 5 of the interview outline (Appendix C). 3.3.5 Issues, improvements and FOSS For ISs that have already been fully implemented, the issues and room for improvement in those systems were investigated. Also the management inclination towards using FOSS components as a viable option to resolve those issues and to make improvements were investigated. The perceived areas where FOSS could be 15
used most advantageously have been investigated. Sections 6 and 7 of the interview outline (Appendix C) cover these aspects.
16
CHAPTER 4: RESEARCH FINDINGS This section consists of a presentation of the research findings. The findings have been classified based on different criteria that were examined during the interviews. Data from these classifications will be referred to in the analysis and conclusions chapter that follows.
4.1 Spread of the investigated projects Based on the research findings, the spread of the investigated IS can be categorized as follows. 1. Implementation stage of the project The implementation stage of the IS projects were identified as projects in the design stage, projects that are already implemented or projects that are currently being implemented. 2. ICTA guided and non-ICTA projects The projects could also be categorized as projects that are guided by the ICTA and projects that are done without ICTA involvement. 3. Inclusion of FOSS/ non-FOSS components in the project Some of the investigated projects consist of mostly FOSS components while the certain other projects consist of mostly non-FOSS(proprietary) components. Therefore the projects can be classified based on this criterion. 4. Nature of Specification Development The projects can also be categorized based on who developed the specifications. Section 4.3 explains this in detail.
17
4.1.1 Implementation stage of the project Design 16%
Implementing 7%
Implmented 77%
Figure 5: Implementation stage of investigated IS
The spread of IS based on the stage of implementation are as indicated in Figure 5. More than three fourths of the investigated IS have already been implemented. A smaller number are at the design stage or are being implemented at the moment.
18
4.1.2 ICTA guided and non-ICTA projects
ICTA 42%
Non ICTA 58%
Figure 6: Spread of ICTA and non-ICTA projects
The spread of investigated IS between ICTA guided projects and non-ICTA projects are as indicated in Figure 6. There is a fair representation of IS from either category. 4.1.3 The use of FOSS/ Proprietary software in the project
FOSS 32%
Proprietary 68%
Figure 7: The use of FOSS components in IS investigated 19
As portrayed above (Figure 7), out of the IS that were investigated less than half had FOSS components involved. . 4.1.4 Nature of Specifications Development and Implementation It has been attempted to analyze the factors based on how the requirements specifications were developed and implemented. The following categories have been identified during the study as possible methods of developing the requirements specifications.
Developed by internal Staff
Developed by External Consultants
ICTA guided via a SAGE
PPP
The spread of projects within these categories are illustrated in Figure 8.
20
PPP 11% ICTA/SAGE 21%
Developed by External Consultant 7%
Developed by internal Staff 61%
Figure 8: Projects by nature of specifications development
The impact of the identified factors has been analyzed based on the above categories in the next sections.
4.2 Factor identification The factors identified generally in the literature survey have been further refined by the findings of the research. The refined factors identified during the course of the research as factors affecting the choice of software for government sector enterprise applications are as follows.

Cost The cost of the project was identified as a decisive factor in most projects. The cost consists of the entire cost of the project.
21
Technical Compliance Technical compliance was identified was identified as an important factor in most projects. As explained in section 5.2.2, this was especially mentioned in projects where the IS concerned would depend on legacy systems.
Usability Usability refers to the usability of the IS by the intended users.
Bidders/Developers Expertise in the selected Technology This refers to the area of technical expertise of the bidders/developers of the project. For example the area of expertise could be a certain proprietary technology stack, as explained in section 5.6.4.
Users Expertise in the selected Technology This refers to the area of expertise of the users.
Interoperability and Open Standards This refers to the ability of the IS to work with other disparate systems by adhering to Open Standards.
Trilingual support This refers to ability of the IS to support Sinhala and Tamil apart from English. Emphasis is given on the ability to support Sinhala and Tamil Unicode.
22
Support and Maintenance This is the degree of support and maintenance that is provided by the system implementers. It also includes the availability of support for the IS by other companies after the existing support contract is over.
Security This factor refers to the security issues pertaining to the IS concerned. Issues like software vulnerabilities and updates/fixes are considered.
Reliability This factor refers to the reliability of the IS concerned. Issues like permissible system downtimes are considered.
Extendibility This factor considers the ability to easily extended the IS in the future to add extra functionality.
These factors have been analyzed in detail in the next chapter.
23
CHAPTER 5: ANALYSIS AND CONCLUSIONS The identified factors that influence the choice of software for enterprise applications in the government sector have been described in the previous chapter. The spread of these factors among the investigated government sector IS projects are graphically depicted in Figure 9. In other words, the figure shows the proportion of projects that highlighted each factor as influential in the choice of software for enterprise applications.
100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0%
Figure 9: Spread of the identified factors among the investigated projects
24
The factors that have the highest representation among the investigated projects can be identified as the most common factors. Based on this rationale, the following factors have been identified as the most common factors.
Technical compliance
Cost
Bidder/developer expertise
Support and maintenance
Each of these has been analyzed in depth in the following sections. The analysis has been accompanied by conclusions arrived at, where relevant. This is followed by an analysis based on the method of specification development and implementation.
5.1 Technical compliance In general, this factor considers meeting minimum technical requirements. Apart from these specific technical requirements like compatibility with existing systems and data formats have been considered in certain IS projects. This is addressed in more detail in section 5.2.2. As indicated in Figure 9 all the investigated IS projects have cited meeting minimal technical requirements as an important factor.
The use of technology in IS projects where technical compliance was indicated as an important factor are as indicated in Figure 10. However, this information is of little analytical value in terms of determining whether this factor results in the use of FOSS or proprietary technologies, as all the investigated projects have highlighted it as an important factor.
25
Technical Compliance FOSS 32%
Proprietary 68%
Figure 10: Technology spread of IS that considered technical compliance as an influential factor
5.2 Cost
Cost FOSS 34%
Proprietary 66%
Figure 11: Technology spread of IS that considered Cost as an influential factor 26
The cost of the IS has been identified as an influential factor in more than 90% of the investigated IS projects (Refer Figure 9). For IS projects that highlighted cost as an influential factor, the percentage of projects that used FOSS and proprietary components are as indicated in Figure 11.
Based on the literature reviewed, it was revealed that the use of FOSS can significantly lower the cost of the IS. However, it is interesting to note that 66% of the IS projects that considered the cost to be an important factor have used proprietary software. Further investigation reveals that cost alone is not a decisive factor in the choice of FOSS or proprietary software. The other factors identified during this research tend to override the cost, depending on the context. Some of these factors are as follows. 
Bidders/Developers Expertise in selected Technology

Users Expertise in selected Technology

Support and maintenance
These factors have been analyzed in the forthcoming sections. Apart from these, the following reasons have been identified on a case by case basis for not basing the cost as the ultimate decisive factor.
5.2.1 Total cost vs. the cost of the IS component In certain large projects the cost of the IS component is relatively small compared to the cost of the total project. For example, in the CEB power systems the total cost of a power station is very large when compared to its IS component. Is such situations the cost alone does not suffice to be a decisive factor in the choice for software for the IS component. It is considered more important that the, IS component integrates well with the rest of the equipment. Hence, the IS component is also procured from the same group of vendors who install the equipment, as one package. 27
5.2.2 Compliance with existing technology Certain IS projects require migration of data from existing systems which happen to be implemented using proprietary technologies. In such situations the new IS has also been implemented using the same product family, for the sake of convenience in data migration.
For example the Department of Education has had its data in an IBM mainframe since 1974. This system was migrated to the IBM AS/400 platform in 1998 as the migration of the past data was easier within the selected platform.
In such situations, the cost of the IS alone has not been considered as decisive factor in the choice of software. And quite naturally, FOSS has not been considered in the selection of software technologies.
5.2.3 Use of unlicensed proprietary software Apart from the factors discussed before, the use of unlicensed proprietary software makes the cost of such software unrealistically lower.
This could also be a
contributory factor to the higher proportion of proprietary software that have been used in IS although the cost has been highlighted as an important factor in those projects. It is quite recently that the legal infrastructure in Sri Lanka was augmented to prosecute crimes related to software and data protection with the introduction of the Electronic Transactions Act in 2006 (Electronic Transactions Act 2006) and the Computer Crimes Act in 2007 (Computer Crimes Act 2007). Therefore, certain older proprietary IS software used for enterprise applications are not licensed versions. Although a detail study on the use of unlicensed software is not within the scope of this research, it can be safely assumed that a considerable amount of older enterprise web and email systems included in this study that use proprietary technologies are not licensed. 28
5.2.4 Conclusions Based on this analysis, it can be concluded that although, the cost of the IS has been highlighted as an influential factor in a majority of the investigated IS, it does not always trickle down to the software selection decision due to other overriding factors. Therefore, the choice of FOSS or proprietary software for the investigated projects is not always directly influenced by the cost of the IS.
It is interesting however; to see how the cost has been incorporated as a decisive factor in certain IS projects. One such methodology is the “The 80-20 Rule� adopted by ICTA guided projects as explained below.
5.2.5 Methods of highlighting the cost as an important factor In certain ICTA guided projects where the cost is a decisive factor, the cost of the projects has been given prominence in the requirements specification by using the 8020 rule. This is where the final selection is done by allowing an 80% weight on the cost of the bid while a weight of 20% is given on technical specifications. This rule has been used to indicate to bidders that cost is an important factor in the selection process. In such situations, certain vendors have considered FOSS components in the proposed solutions.
5.3 Bidder/developer expertise The technology of expertise of the bidders or the developers has been found to be an important factor in more than 50% of the investigated projects (Refer Figure 9). The nature of the software technology used in these projects is as illustrated in Figure 12. It is interesting to note that a vast majority of the projects that considered this factor as important were associated with proprietary technologies. Further investigation revealed that the reason for selecting proprietary software technologies for these 29
projects was because the expertise of the developer or service provider was limited to that particular proprietary technology.
Bidders/Developers Expertise in the selected Technology FOSS 6%
Proprietary 94%
Figure 12: Technology spread of IS that considered bidder/developer expertise as an influential factor Several examples can be highlighted to illustrate this fact. 5.3.1 GIC Project The GIC project is implemented as a public private partnership (PPP) with a private process outsourcing company. The project involves three separate IS. All three IS of the project were implemented using a particular proprietary technology. It was revealed that the reason for choosing this proprietary technology stack was because the expertise of the private entity was limited to that particular technology. However, 30
it is important to note that the requirements specification given was technology agnostic. 5.3.2 Internally developed system The same holds for certain internally developed IS as well. For example the IS projects developed internally at the Sri Lanka Customs have been done in the using Microsoft Visual Basic as the expertise of the internal developers was in this area. Due to this same reason, the „Grama Niladari Databases‟ and „Project Monitoring Systems‟ of the Ministry of Public Administration have been developed using the MS.net/SQL Server stack. The choice of technology is not limited to the Microsoft product family. The consumer billing system of the CEB was developed using a proprietary Unix based technology, also as the internal expertise lay in that technology.
5.3.3 Conclusions Based on this analysis, it can be concluded that the technological expertise of the bidders and developers can strongly affect the technology chosen to implement the IS. It can also be concluded that in enterprise IS projects where this factor was highlighted as important, a majority of the solutions were implemented using proprietary technologies as the expertise of the implementers lay in that particular proprietary technology.
31
5.4 Support and maintenance
Support and Maintennance FOSS 31%
Proprietary 69%
Figure 13: Technology spread of IS that considered support and maintenance as an influential factor
5.4.1 Statistical perspective In around 40% of the investigated IS projects, support and maintenance was highlighted as an important factor that affects the choice of software (Refer Figure 8). The technology spread of projects that highlighted this factor are shown in Figure 13. It can be seen that almost 70% of the projects where support and maintenance was considered important were associated with proprietary software. Therefore, statistics seem to indicate that the lack of FOSS companies to provide support and maintenance could have influenced IS projects to be implemented using proprietary software where support and maintenance was considered as an important factor.
32
5.4.2 A different scenario An interesting situation was discovered however, at the TVEC MIS project which was initially developed by an external consultant using a proprietary technology stack. However, when the consultant ran out of business, there was no means of obtaining support and maintenance for the MIS which was custom built for the TVEC. Therefore the management has initiated implementing the second phase of the MIS using a FOSS tool, with the aid of internal staff, who are somewhat FOSS savvy.
5.4.3 Conclusion Based on the above analysis we can conclude that projects where support and maintenance is considered as an important factor have a preference for selecting proprietary software technologies. We can also conclude from the above information that the selection proprietary software does not necessarily always guarantee good support and maintenance of the implemented IS.
5.5 Factor summary It was analyzed in section 5.2 that although the cost was mentioned as an important factor in most of the investigated IS, it did not indicate a strong correlation between the choice of FOSS or proprietary software for implementing the IS. This was due to other overriding factors.
In addition to this, the factors affecting the choice of
software for enterprise IS in the government sector that were analyzed so far have been graphically summarized in Figure 14. A comparative analysis of the use of FOSS and proprietary software among IS that considered each of the factors as important, reveals the following fact. There is a considerably low proportion of FOSS usage in IS projects where the bidders/developers expertise in a particular technology was considered as an important factor. Therefore it can be concluded that the lack of FOSS expertise among bidders/developers is a strong reason for not using FOSS is government sector IS projects.
33
Factor Summary
Support and Maintennance
Bidders/Developers Expertise in selected Technology FOSS Proprietary Technical Compliance
Cost
0%
20%
40%
60%
80%
100%
Figure 14: Factor summary
5.6 Analysis based on specification development and implementation methodology The use of FOSS and proprietary software in the investigated IS can be further analyzed based on the nature of specifications development and implementation methodology used. The following categories have been included in this analysis.
ICTA/SAGE
External consultant
Developed in-house
PPP
34
5.6.1 ICTA/SAGE These are enterprise IS that are implemented with the ICTA guidance. Therefore the specifications are developed with guidance of the ICTA via a Software Architecture Group of Experts (SAGE). The SAGE consists of domain experts from industry as well as from the academia.
The use of FOSS and proprietary software in these projects are shown graphically in Figure 15. Both FOSS and proprietary software seem to be used almost equally with FOSS being used more.
ICTA/SAGE Proprietary 40%
FOSS 60%
Figure 15: The spread of technology in ICTA/SAGE projects
Some salient points in the use of FOSS in the ICTA/SAGE projects have been analyzed as follows.
35
5.6.1.1 Replication Cost when scaling up The BMD project which is guided by the ICTA was initially deployed using a particular proprietary solution stack. However, when the solution had to be scaled up across several divisional secretariats, the licensing costs of scaling up was projected to be too high. Therefore, it was decided to incorporate FOSS when replicating the solution to other divisional secretariats.
5.6.1.2 Interoperability and Open standards. Certain ICTA guided projects like the ePensions project and the eSamurdhi project are currently in the design stage. The design of these IS have incorporated FOSS in order to ensure open standards and interoperability. This is because these IS are required to interoperate with IS that will be used in other e-government services. Based on the same rationale, the eLocal Government Project, which is currently in the system study level, is aimed to be completely FOSS based.
5.6.1.3 Conclusions Hence it can be concluded that FOSS has been included in ICTA/SAGE guided enterprise solutions to achieve cost advantages in large scale replication of systems. It can also be concluded that FOSS has been used to ensure interoperability with other government IS via compliance with open standards.
36
5.6.2 External consultant
Consultant FOSS 33%
Proprietary 67%
Figure 16: The spread of technology in projects where external consultants were involved
For IS projects that involved external consultants it is shown that a larger proportion were based on proprietary software technologies. It can be assumed
that the
consultants familiarity in a particular technology stack would have influenced the decision to recommend that particular technology.
5.6.3 Developed in-house When analyzing the proportion of FOSS and proprietary IS that were developed inhouse, we see that more than 70% used proprietary software (Figure 17).
The
underlying reason behind this is that the expertise of the internal developers of those IS was in proprietary technologies. Therefore, it can be concluded that the lack of FOSS expertise among internal developers is a cause for the lower proportion of FOSS used in IS that were developed in-house. 37
In-house FOSS 29%
Proprietary 71%
Figure 17: The spread of technology in projects that were developed in-house
5.6.4 PPP The IS investigated under the PPP category consisted of the IS of the GIC project. It was found that all these IS were implemented in a particular proprietary software technology stack. As explained in section 5.3.1 the reason for this choice was because the expertise of the private entity was limited to this proprietary software technology stack .
5.6.5 Summary of analysis by specifications development and implementation It can be seen from the comparative analysis in Figure 18 that ISs in the PPP category were implemented completely in proprietary software. The reason for this was analyzed in the previous sections (sections 5.3.1 and 5.6.4) as bidder/developer expertise.
38
A combination of FOSS and proprietary software can be seen in the other three categories. Out of these an interesting trend can be observed in the ICTA/SAGE projects as opposed to the IS developed in-house and IS done through consultants. The ICTA/SAGE projects seem to have higher proportion of IS that use FOSS (Refer Figure 18) when compared to IS that use proprietary software. Further investigation revealed that this was influenced by the fact that the ICTA has a considerable amount of FOSS expertise and awareness.
Summary of analysis by specifications development and implementation
PPP
ICTA/SAGE FOSS Proprietary Consultant
Inhouse
0%
20%
40%
60%
80%
100%
Figure 18: Summary of analysis by specifications development and implementation
39
CHAPTER 6: RECOMMENDATIONS Based on the analysis and conclusions, the following are recommended for the better selection of enterprise software for the government sector in Sri Lanka.
6.1 Recommendations on building expertise The analysis done in the previous chapter (section 5.5) concludes that a main reason for using proprietary technologies to implement government sector enterprise IS is that the expertise of the bidders, consultants and clients in certain projects were limited to particular proprietary technologies. Therefore, it is recommended that FOSS service provider companies should be nurtured and encouraged to support government sector enterprise IS development. This should encourage organizations where FOSS expertise exists, to provide FOSS services to government sector IS projects. This could include local Universities, for example. Since, government IS will have long term benefits by leveraging on FOSS components, nurturing a FOSS ecosystem with companies that provide FOSS solutions will be a win-win situation for the government as well as for those organizations.
6.2 Recommendations on developing internal expertise Based on the analysis done in the previous chapter (section 5.6.3), it was concluded that a reason for the use of proprietary software to implement government enterprise IS that were developed by internal staff, was the fact that their expertise was limited to certain proprietary technologies. Therefore, in order to benefit from the advantages of FOSS in government sector enterprise applications, internal expertise within the government organizations should be developed. IT personnel within government organizations should be trained to be FOSS savvy. Technical expertise within the organizations should be capable of maintaining FOSS IS. The following aspect should be considered in achieving this.
40
6.2.1 Knowledge sharing As mentioned in the previous chapter (sections 5.4.2 and 5.6.5) certain organizations like the ICTA and the TVEC possess a certain amount of FOSS expertise. However, many other government organizations lack FOSS expertise although they were aware of FOSS. Therefore, a knowledge sharing mechanism among government (and other) organizations should be encouraged. This will facilitate the sharing of support and maintenance experience of FOSS solutions which would otherwise remain in silos. It is also noted that the staff in government organizations may be more receptive towards experience shared by staff from another government organization as opposed to what is advocated by a non-government entity.
6.3 Technical compatibility with legacy systems It was discussed in the analysis and conclusions chapter (sections 5.1 and 5.2.2) that the requirement for new systems to merge with older legacy systems has locked in the choice of technology to certain proprietary technologies. This makes it difficult to benefit from the use of FOSS when implementing new IS in organizations that are already using such proprietary legacy systems. However, it is recommended that suitable technologies which bridge FOSS with legacy proprietary systems (for example ODBC drivers for legacy DBMS) should be researched and identified when implementing such IS. Also as explained in recommendation Error! Reference source not found., interoperability and open standards should be considered when implementing new IS, so that vendor lock in is avoided in future IS.
6.4 Recommendations on developing specifications It was seen during the analysis that the area of technical expertise of the specifications developers had a strong influence on the technology used in the final solution. Therefore, it is recommended that experts who are knowledgeable about FOSS should be included in the team when developing specifications of the IS.
41
6.5 Concluding remarks The factors that affect the selection of software technologies for government sector enterprise applications have been identified and analyzed in this study. It can be concluded that certain specific factors restrain government sector enterprise IS, from leveraging on the benefits of FOSS. Based on this analysis and conclusions, the above recommendations have been made, so as to benefit from FOSS in government sector enterprise IS.
42
REFERENCES Computer Crime Act, No.24 of 2007, Gazette of the Democratic Socialist Republic of Sri Lanka
Chan, A. S. (2007) Retiring the Network Spokesman, Science Studies 20 :78-99.
Dedrick, J. and West, J. (2003) A Grounded Theory of Innovation and Standards Adoption,� Proceedings of the Workshop on Standard Making: A Critical Research Frontier for Information Systems (MISQ Special Issue Workshop):1214.
Delone, W.H. and McLean, E.R (1992) Information systems success: The quest for the dependent variable, Information Systems Research 3(1):60-95.
Delone, W.H. and McLean, E.R (2003) Journal of Management Information Systems 19 (4):9-30.
Electronic Transactions Act, No. 19 of 2006, Gazette of the Democratic Socialist Republic of Sri Lanka
Free Software Foundation (2005), accessed on 10-01-2008, < http://www.gnu.org/philosophy/free-sw.html>
Gable, Guy, Sedera, Darshana, Chan and Taizan (2003) Enterprise systems success: a measurement model, Proceeding of the 24th International Conference on Information Systems, Seattle, USA:576-591.
43
Hanna N. K. (2006) From Envisioning to Designing e-Development: The Experience of Sri Lanka, World Bank Publications:179-181.
Kenneth Wong (2004) Free/Open Source Software: Government Policy, Asia-Pacific Development Information Programme, ELSEVIER, accessed on 02-05-2008, <http://www.iosn.net/government/foss-government-primer/foss-govt-policy.pdf >
Kwan, S. K and West, J. (2005) A conceptual model for enterprise adoption of open source software,â&#x20AC;? The Standards Edge: Open Season. Sheridan Books, Ann Arbor, Michigan.
Lemos, R. (2003) Merrill Lynch: Linux saves money, 7 June, CNet News.com, accessed
on
27-06-2008,
<http://news.com.com/2100-1016_3-
1014287.html?tag=fd_to>
Maguire, J. (2003) Windows vs. Linux: TCO Feud Rages On, Newsfactor Network, accessed on 27-06-2008, <http://www.newsfactor.com/perl/story/22012.html>
Orzech, D. (2002) Linux TCO: Less Than Half The Cost of Windows, CIO Update, accessed on 27-06-2008, <http://www.cioupdate.com/article.php/10493_147791>
Reddy, B. and Evans, D. (2002) Government Preferences for Promoting Open-Source Software: A Solution in Search of a Problem, Social Sciences Research Network, accessed on 01-05-2008, <http://papers.ssrn.com/sol3/papers.cfm?abstract_id=313202#PaperDownload>
Schindler Esther (2008) Open Source is Entering the Enterprise Mainstream - Survey Shows, CIO.com, accessed on 27-06-2008, 44
<http://www.cio.com/article/375916/Open_Source_is_Entering_the_Enterprise_ Mainstream_Survey_Shows>
Stoltz, M. (1999) The Case for Government Promotion of Open Source Software, NetAction (27), accessed on 05-05-2008, <http:// www. netaction. org/opensrc/oss-report.html>
Wong Kenneth (2004) Free/Open Source Software:Government Policy, United Nations Development Programme - Asia Pacific Development Information Programme (UNDP-APDIP), ELSEVIER.
Yin R.K. (2003) Case study research: design and methods, 3rd edition, Sage Publications Inc, USA.
45
APPENDIX A Table 1: List of organizations and organization codes Organization
Code
Ceylon Electricity Board
CEB
Department of Agriculture
DeptAgri
Department of Education
DeptEdu
Divisional Secretariats
DivSec
Department of Local Governments
LocalGov
Foreign Employment Bureau
FEB
ICT Agency of Sri Lanka
ICTA
Ministry of Public Administration
PubAdmin
Sri Lanka Customs
Customs
State Engineering Corporation
SEC
Tertiary
and
Vocational
Education TVEC
Commission
46
APPENDIX B List of IS projects investigated are as follows. Please refer Appendix A for organization codes.
Table 2: Investigated IS Projects Project
Organization
Accounting and Inventory System
CEB
Bill of Quantities System
SEC
Birth Medical Death Records (BMD)
ICTA
Project Call Center
DeptAgri
Consumer Billing System
CEB
CRM System
GIC/ICTA
e-Divisional Secretariats Project (EDS)
ICTA/ DivSec
e-Foreign Employment Bureau Project
ICTA / FEB
(EFB) E-Learning System
TVEC
E-Learning System
DeptAgri
EHRM System
ICTA/ PubAdmin
eLocal Government Project
ICTA/LocalGov
ePensions Project
ICTA/PensionsDept
eSamurdhi Project
ICTA/SamurdhiAuthority
Examination Processing System
DeptEdu
Goodes Processing System
Customs
Grama Niladari HR System
PubAdmin 47
Inventory System
SEC
LGN Phase 1
ICTA
Mail Server
SEC
Management Information System
TVEC
Motor Vehicle Records System
Customs
Payroll System
SEC
Power System Control Systems
CEB
Warehouse Monitoring System
Customs
Web Information System
DeptAgri
Web/Email System
PubAdmin
48
APPENDIX C The outline of the conducted interviews was as follows.
1. What are the IS projects in your organization and what are the components of those projects? 2. What technology, HW, SW or middleware components were used? Were any FOSS components used? 3. How were the specifications of the project developed? 4. Who are the key people involved in the selection decision? 5. Procurement process. a) In your procurement process what are the factors that influence the selection? b) How do you rank these factors based on their importance for the existing procurement process? c) Do you have any recommendations to improve the selection process? 6. Issues and room for improvement. a) If the system is up and running, are there any issues in it? b) In the selected system what areas need improvement? c) Which parts of it are you happy with and which parts are you not satisfied? d) For the unsatisfied areas, do you see FOSS as a viable option? 7. In your opinion in what areas would FOSS be more advantages to you?
49