1

SWOT analysis on using
Open Source Software in
companies ­ a literature
review

Jukka Keinänen, Rainer Koirikivi & Riikka Vuorio
 2

Abstract
The  purpose  of this  article  was to  analyse  the strengths,  weaknesses, opportunities and threats
(SWOT  analyse)  of  companies  using  open  source  software  (OSS).   With   SWOT   analysis  we
were  aiming  to  get  insight  into OSS  usage from the business perspective; OSS are widely used
today  by  companies  with  varying  level.  Some  companies  are  utilizing  OSS  as  it is  without even
realizing  that  they  use  an  OSS  product,  while  some  companies  may  participate  in open source
projects   and   even  launch  new  open  source  communities.   The  amount  of  OSS  and  its  use  is
increasing  and  it  is  assumable  that  the  open   source   phenomenon  is  here  to  stay  and  that  its
significance for businesses is also increasing.

Perhaps  the  first  characteristic  we  think  when  considering  OSS  is  that  it  is  free  of  charge,  and
that  when  we  are  dealing  with  the  OSS,  we are also dealing with licences. However, using OSS
involves  much  more  than  that,  and  by  a  SWOT  analysis based on a literature review, we’ll bring
out the other aspects too.

A  company  that  is  considering  using  OSS  should  be  aware  of  the  certain  challenges.  Without
knowledge  about  the  open  source  in  general  or   not  having  experience  from  a  certain  open
source  project,  a  company  may  face  some  unexpected  issues.  This  can  delay  projects  and
complicate the project management outstandingly.

Depending  on  the  used  OSS,  a  company  may  gain  advantage  from  OSS.  The  company  does
not  have  to  reinvent  the  wheel and it may economize development costs. Involving with the OSS
projects  can  also  have  positive side  effects  in  addition  to these essential and expected benefits.
For  an  example  intellectual  energy  is captured when a company learns through the open source
projects’  effective  processes,  obtains  resources  such  as  code   and  has  a  possibility  to  recruit
knowledgeable people.

The  article  concludes  that  to  gain  advantage  from  OSS,  a   company  should carefully  consider
specific  issues   such  as  the  total  cost­benefit  analysis,  licenses,  intellectual  property  rights  and
business  models  –  the  use  of  OSS  requires  a  comprehensive  plan,  which  involves  the  whole
organization.
 3

Contents

Abstract
Contents
1. Introduction
2. SWOT analysis
2.1 Strengths
2.2 Weaknesses
2.3 Opportunities
2.4 Threats
3. Discussion
4. Conclusions
REFERENCES

1. Introduction

The Open Source Initiative (http://opensource.org/docs/osd) defines open source software with
following criterias: Open source software must be freely distributed. The software must include
its source code and also allow its distributing. Derived works and modifications must be allowed.
The integrity of the author’s source code must be kept ­ license may require that the derived
works must be released with different names. There should be no discrimination against
persons, groups or fields of endeavor. The license must apply to all those whom the software
has been distributed. The license should not restrict other software. The license must be
technology neutral, meaning that it must not be related to style of interface.

The purpose of this article ­ SWOT analysis on using Open Source Software in companies ­ is
to analyze strengths, weaknesses, opportunities and threats concerning the usage of open
source software in companies. At the end of the article we go through various reasons and
conclusions behind our findings.

We find this topic important, since companies around the world use more and more open
source software. The scale of usage can be very wide. The usage may vary from everyday,
small tasks, to even more specific usage like server software applications. We believe that
nowadays companies may not even realize that the software they are using is open sourced, for
example when they use the Mozilla Firefox web browser. On the other hand, many companies –
especially software development companies – base a lot of thought on their use of open source
 4

software and the relationship between them and the open source communities, and may even
base their whole business models around open source software.

The research method of this article is literature review. This article goes through previous
scientific studies, that go through various strengths, weaknesses, opportunities and threats
related to using open source software in many sized companies. This article is looking to
answer this research question: What kind of strengths, weaknesses, opportunities and threats
there are when companies are dealing with open source software? This article has been limited
so that strengths, weaknesses, opportunities and threats are considered on very general level.

This article focuses on the general case of a company using open source software. This
includes both the simple “use” of applications (like an open source web browser or word
processor), and the use of open source in a software development sense, for an instance by
using open source libraries and licensing one’s code under an open source license. Still, the
focus is leaned a bit on the side of adopting OSS application usage by companies.

This article has been constructed so that the first part of the article goes through the strengths,
weaknesses, opportunities, and threats one by one. Second part of this article contains
discussions and at the end of the article we provide conclusions.

2. SWOT analysis

Dr. Rod Kuhn King (2004) states that SWOT analysis is the most popular tool in strategic
planning and solving organizational problems. Kuhn King (2004) also mentions that SWOT
analysis can be used in learning and getting insight into certain issues. In this chapter we provide
insight into strengths, weaknesses, opportunities and threats when using open source software
in companies.

2.1 Strengths

Perhaps the most obvious advantage of using open source software is that it’s generally free in
terms of acquisition costs and licensing fees (Ebert, 2008; Ven, Verelst & Mannaert, 2008;
Dehinbo, Pretorius, & Dehinbo, 2012). This results in an obvious cost advantage (though other,
hidden costs need to be taken into account; see the section on weaknesses), and is often cited
by companies as a driving factor for open source adoption (Ven et al., 2008). Also, in some
cases, switching to open source software (e.g. Linux) has also resulted in decreased hardware
 5

costs (Ven et al. 2008), though this depends on a case by case basis. In any case, the fact that
a company doesn’t have to pay for a piece of software it is using means not only that it saves in
acquisition, but that trying out a new piece of software is easier and cheaper, which is further
aided by the fact that virtually all open source software is downloadable from the internet. As
such, when considering the adoption of new software, a company can just allocate some
man­hours to try out various open source alternatives without having to pay a fee for each, and
without limiting themselves to limited applications, as is often the case with demo versions of
proprietary software.

The quality and security of open source software is generally considered good. This is partly
because the code is open for anyone to analyze, and partly because new contributions often go
through a strict peer review. (Ebert, 2008, Ven et al. 2008, Dehinbo et al. 2012) For an instance,
the Apache HTTP Server project maintains a strict review­then­commit policy for new
developers (though trusted developers get to commit first if they feel that it’s necessary, but their
code gets reviewed too) (Rigby, German & Storey, 2008). In any case, Bugs and security
vulnerabilities are reduced, and fixed quickly when found.

Partly because of the peer review practices, many open source software projects are deemed
more mature than their proprietary counterparts, and many are backed up by commercial
software companies (Ven et al. 2008) One good example is the aforementioned Apache server ,
which enjoys an industry­standard status (Rigby et al. 2009). Adopting mature software reduces
risks and costs caused by software defects, and is a real motivator for many companies.

The availability of the source code of open source software also lets a company study the
software and modify it according to its needs. This is especially interesting for companies that
are developing open source applications themselves. (Ven et al. 2008) Software engineers
experience the most obvious benefits, since they can study the software and libraries they are
using and interfacing with, and fix bugs if found. As such, it should not be surprise that it has
been shown that the users most happy with their decision to adopt open source software are
expert programmers that actually modify the software according to their needs. (Dedric & West,
2004)

Since the supplying of open source software is distributed across multiple individual vendors,
thee associated risk of one vendor stopping supporting a supporting a piece of software is
reduced (Ebert, 2008; Ven et al. 2008). This risk is also further mitigated by the fact that many
open source components have evolved into de facto standards, for an example in terms of
binary compatibility (Ebert, 2008). Actually, as Raymond (1999, 2) points out, in many cases the
risk might not come from an outside vendor at all, but from the developer itself. Who is going to
maintain the code if the developer switches jobs, falls ill or is hands full with other projects? By
open sourcing (or adapting open source products), the developer community grows and reduces
the risk put on a single person.
 6

2.2 Weaknesses

Even  though  using  OSS is  concerned  to  have  many  benefits it is not still “free”, even though the

development  costs  of the software might be cut by using well­proofed OSS. Using OSS requires
new   kind  of   knowledge  and  skills,  and  time  may  be  used  on  different  kind  of  tasks  than  in  a
proprietary  software  development project. Many open  source  software projects do not provide an
end­to­end solution (Gary, Koehnemann, Blankey, Goar, Mann & Kagan, 2009), do not  satisfy the
requirements   of  a  company,  or  do  not  integrate  well  together when  two  or  more  OSS  are  used
(Ven  &  Mannaert,  2007).  Thus  using  of  OSS  does  not  automatically  mean that there  is no work
to  be  done –  sometimes  OSS  requires custom changes or “glue code” (Ven & Mannaert, 2007).
In   some  cases,   if  a  company  does  not  have  enough  knowledge  about  the  used  component  or
software, the amount of customizing work might come as a surprise.

Although  open  source  software  is  generally  free  in   terms  of  licensing  fees,  licensing  fees  may
still  be  indirectly  involved.  An  example  is enterprise  Linux  distributions, which are in theory freely
available,  but  offer  additional  services  for  enterprise  customers  for  a  fee  (Ven  et  al.,  2008).
These  services  –  and  as  such,  the payment  –  are  often  required to  get  support  for  the  system
from  vendors  of  other  products  used  by  a  company  (Ven  et  al.  2008).  As  such,  the  company
ends  up  paying  for the open source product, such as they would have with a proprietary product.
In  other  cases,  using  an open  source  software  might  be  free,  but incorporating it into one’s own
software  might  require  licensing  all  the  software  under  an  open  source  license  (as  is  the  case
with  GPL),  which  would  incur  devastating  cost.  In  such  cases,  the  software  is  often
dual­licensed  by  the  company  that  owns  its  copyright,  and  a  commercial  license,  for which one
has  to  pay,  is  provided  as  an alternative (Ven et al., 2008). As such, open source software is not
necessarily less expensive than proprietary software (Ven et al., 2008).

One  potential  and  realistic  problem  is  that  OSS  legal  infrastructure  within  organization  is  not
understood  in  the  first  place.  A  solid  legal  infrastructure  is  undoubtedly  an  absolute  key  to  the
success  of  company  utilizing OSS  (Ågerfalk,  Deverell,  Fitzgerald  &  Lorraine,  2005).  Intellectual
property  and  patents  issues  are  complicated  and   there  is  a  risk  that  code  is illegally  used  and
propagated  (Stol  &  Ali  Babar,  2010).  Also  licenses   are  complex  –  there  is  over  60  different
licenses  that  comply  with  the  open  source  definition  (Stol  &  Ali  Babar,  2010) and understanding
the  details  of  every  licenses  is  very  challenging.  Even  companies’  legal  teams  may  not
necessarily understand the OSS licenses (Ågerfalk, Deverell, Fitzgerald & Lorraine, 2005).

As   with  adopting  any  new  technology,  resources  are  required  for  switching  to  an  open  source
from  a  proprietary  system.  This  results  in  further  expenses  in  the  form  of   switching  costs.
Examples  include  migration of data and retraining personnel. As such, the actual cost advantage
of  open  source  software over  proprietary  software  may  be disputed – even if the initial costs are
lower  or  even  free,  the adoption  itself,  along with  other hidden costs, might raise the total cost of
an  open  source  software  even  higher  than  just   sticking   with  a  proprietary  version  (Ven  et  al.,
 7

2008).   This  is,  of  course,  only  directly  applicable  in  the  case  when  a  company  already  has  a
system   in  place  –  companies  adopting  a  totally  new  system  with  no  existing  system  to  replace
don’t  have  to worry  about  migration  or  retraining  of  personnel and such, though the cost of initial
training still needs to be taken into account.

The  selection  of  the  open  source  product  to  be  used  may  not  be  straightforward  (Merilinna  &
Matinlassi,  2006).  Choosing  the proper  product  amongst  the  multitude  of  projects  and  products
may  be  challenging,  as  the  company  should  find  the  technical  solution  that  is  right  for  their
current problem or project (Ågerfalk, Deverell, Fitzgerald & Lorraine, 2005; Merilinna & Matinlassi,
2006).   Replaying  and  evaluating  a  large  amount  of  projects  and  products  to  find  out  the  quality
issues   such  as  usability,  stability  and  reliability  (Stol  &  Ali  Babar,  2010)  is  time­consuming,  and
as  such,  expensive,  even  when the acquisition  of the software for testing is free. In some cases,
an  open  source  product  has  multiple  forks  of  it  (perhaps  most  obvious  with  the  hundreds  of
Linux  distributions  out  there),  and  the  company  needs to also make a decision of which fork of a
project to use, which might cause a temporary delay in the project (Stol & Ali Babar, 2010).

There  is  no  known  common  practice  for  documenting  OSS  in  the  way  that  is  would  make
systematic  OSS   evaluation  easier  (Merilinna  &  Matinlassi,  2006).  Some  OSS  evaluation
methods  and frameworks such as Capgemini’s Open Source Maturity Model (OSMM) exists, but
research  has  shown  that  these evaluation  methods  and frameworks  are  not typically used (Stol
&  Ali  Babar,  2010).  If  company  does  not  have   a  strong   knowledge  and  experience  about  the
possible  product  candidates  and  if  company  has  not  time  to  do evaluation  properly  it  might  end
up with a wrong pick.

In   addition  to  skills  and  knowledge  company  needs   also  clear  strategy  for  using  an  OSS.  In
addition  to  license  and  intellectual  property  rights  issues,  company  needs  to  solve the business
model.  The  integration  of  OSS  into  business  requires  an  understanding  of  the  OSS  community
and  the  particular needs  of  the  business  (Munga,  Fogwill  &  Williams, 2009). Company needs to
adapt   business  models  by  making  OSS  a  fundamental  part  of  the  business  model.  Questions
such  as  ‘how  OSS  will  be used’, ‘how  will  OSS  be  implemented  in the organization’, ‘what it will
cost’,  ‘who  will  be  responsible  for  maintaining  it’  and  how  ‘will  OSS  be  used  and  maintained  in
the future’ need to be answered (Munga, Fogwill & Williams, 2009).

Especially  the  two  last  questions  are  challenging.  As  mentioned earlier, it is quite often the case

that  OSS  products  need to  be  modified  in  order  to  better  integrate  with  other  components  or  to
offer  the  needed  functionality.  This  raises  a  fundamental   question:  How  to  maintain  these
customized versions of OSS products/components and handle the extensions and modifications
in  the   future?  Especially  for  small  companies  with  limited  resources,  an  appropriate  strategy  is
crucial  –  choosing  the  wrong  strategy  may  impact  the  further  expansions  and  changes  (Ven  &
Mannaert,   2007).  Not  contributing  the  modifications  back  to   the  community  is  one  option.
However,  there   is  an  expectation  that  companies  that  use  OSS  outcomes  also  give  something
back  (Gary,  Koehnemann,  Blakley,  Goar,  Mann  &  Kagan,  2009;  Ågerfalk, Deverell,  Fitzgerald  &
Lorraine,  2005).  Even  though  many  companies  do  want  to  contribute  back  to  OSS  projects  –
 8

because  of  complicated  license  or  motivation  to  be  “a  good OSS  player”  –  some  reason  might
hinder the contribution (Ven & Mannaert, 2007).

One  obvious  reason  might  be  that  contributing  the  changes  back  to  the  community  always
requires  some  resources,  in interacting  with  the  community.  Social  infrastructure,  collaboration
and  clear  hierarchy  are  emphasized  in  OSS  projects  and  communities  (Ven & Mannaert, 2007;
Ågerfalk,  Deverell,  Fitzgerald  &  Lorraine,  2005).  Companies  cannot  just  simply  take  the  outputs
of  a  community  and  give  their  own changes  back.  First,  companies  need  to  be familiar with the
OSS  projects  and  the  specific  practices  it has  as  every  project  has  its  own formal and informal
policies  covering  issues  such  as  how  to  become  a  member   of  the  project  and  how  to  submit
patches   (Ven  &  Manneart,  2007).  Companies  need   to  learn  how  to  build  trust  within  those
communities  and  credibility  is  earned  through  participation  (Ågerfalk,  Deverell,  Fitzgerald  &
Lorraine,  2005; Gary, Koehnemann, Blakley, Goar, Mann & Kagan, 2009), and if company and its
developers  are  not  yet  familiar  with  the  specific  project  and  community,   it  might  take  time.
Developer  may  have  kind  of  learning  period,  in  which  his  or  her  patches  are  not  accepted  first:
for  example  the  patches may not meet the quality assurance  guidelines (Ven & Manneart, 2007).
Especially   influencing  the  architecture  of  an  open  source  component  is  difficult  if  company’s
developer  is  not  a  core  member  of  the  community  (Merilinna  &  Matinlassi,  2006).  While  these
issues   might  be  hard  and  time­consuming  enough  for  individual  developers  trying  to  participate
in  open  source  projects just  as  hobbyists,  they  might  be even worse for companies that have to
pay for the time invested in terms of personnel costs.

Another   issue  is  the  specificness  of  modifications  which  might  prevent  company  to  contribute
back  the   modifications.  The  modifications  may  interest  only  to  a   limited  audience  and  OSS
project  do  not  want  to  jeopardize  long­term  maintenance  and  thus  do  not  accept  the  patches.
Thus  company  have  to  make  patches  more  generic  to  better  fit  into the  OSS  project.  A  similar
situation  occurs  when  the  modifications  have  been  done  just  to  “glue”  the  OSS  component  to
other components. (Ven & Manneart, 2007.)

Indeed,  the  lack  of  skills,  knowledge  and  experience  may  result  in unrealistic  expectations  and
wrong  assumptions  about OSS  and its use. Using an OSS requires careful plans and strategies
and  it  affects the whole organization on its all levels. Ignoring the challenges relating to the use of
OSS,  company  may  face  many  surprises:  exceeded  budgets,  falling  behind  the  schedule  or
even more serious consequences if the legal aspects are not considered carefully.

2.3 Opportunities

By adopting open standards, a company may significantly lower the efforts required when
adopting new open source systems. This can result in opportunities when new, effective
systems arise (Ven et al. 2008). For an example, a company writing their software in the C++
language might decide to only use the standard, open C++ features (and not, for an example,
 9

Microsoft’s proprietary extensions), and compile their software using the open gcc compiler. The
company might then, later, notice, that the LLVM project has some interesting benefits for them,
for an instance, compiling their C++ program to Javascript and running it inside a web browser.
Because the company is using the open C++ standard and a compatible compiler, they might
just switch to LLVM’s C++ compiler and the switch will be much easier than if proprietary
standards were used.

Open source software enables new business possibilities for companies. With annual
subscriptions by their customers, companies like Red Hat and Novell are making high revenues.
This is so called bootstrapping model, where open source products are being used as a
platform. Companies can also add consultancy, service and support for their open source
products and increase the value of the products. (Fitzgerald, 2006)

While the reliability and the low cost of open source software is seen as a great strength,
companies like Amazon and Google have turned that into an opportunity: They offer value­added
services in their own business domains. They are not distributing the software itself, so they
don’t have problems of compliance with GPL­license. (Fitzgerald, 2006)

Open Source Software has given companies opportunities to create new markets and so called
dual­product strategies. Widely known Red Hat is a common example of the dual­product
strategy: Red Hat has a free Linux­based operating system ­ Fedora ­ and they are also offering
Enterprise Linux as a commercial product. The idea behind the dual­product strategy is that
while millions of users are using the free copies, a customer in 1000 purchases a commercial
license. (Fitzgerald, 2006)

Working with open source can help a company to capture intellectual energy, that is, to learn
about effective processes, recruit knowledgeable people and obtain resources such as code.
For best results, the company needs to put some effort into the participation,  but the gains can
be significant for small and large companies alike. (Shaikh & Cornford, 2010) As Raymond
(1999, 1; 1999, 2) put it, it doesn’t cost any more to release a program in the public than to keep
them closed, but the value gained from it can be of great importance. For an instance,
community others might bugs in your code, providing, in essence, free work force. Furthermore,
concentrating the energies of multiple developers working on a problem together (as opposed to
working on it, each alone, re­inventing again and again) can produce really great results, as was
the case with the Apache HTTP Server.

A perhaps less noticed opportunity is that companies that have adopted open source software
may experience productivity and work climate boosts, because their engineers often have the
same open source tools at home, too (Ebert, 2008). This effect may not be only restricted to
engineers, but might apply to other fields too. For an instance, professional image, video and
audio editing software is often very expensive to buy for an individual. With open alternatives, the
individuals could work and practice from home with more freedom.
 10

2.4 Threats

A  company gives up some of the control to an outsider community when it starts to use an OSS.
As   in  OSS  projects  decisions  are  made  as  part  of  the  community,  companies  may  not  have
much  control  over  project’s  direction. For  example  Unicon  Inc.,  which  has  been  developed  and
supported  eLearning  software  products  built  on  top  of  the  uPortal open  source  technology, was
so  dependent  on  uPortal  that  it  caused  them  many  challenges.  Perhaps  the  most  significant
drawback  was  the  instability  of  the  product release cycle: Unicon did not control releases cycles
of   the  uPortal  framework,  so  release  and  configuration  management  was  difficult,  functionality
that  was  planned  for releases of uPortal was often delayed or simply did not completed because
constraints   on  the  contributors  and  the  community  controlled  the  requirements  for  future
releases.  (Gary,   Koehnemann,  Blankey,  Goar,  Mann   &   Kagan,  2009).  In  cases  like  this,  the
company  might   always  fork  the  project,  but  that  would   cause   them  to  lose  much  needed
community   support,  and  require  them  to  manage  pulling  changes in  the  original  project  to  their
fork.

In   addition  to  losing  some  of  the  control,  companies   become  dependent  partly  upon  the
community  as they need information from the community in the form of documentation, technical
support  or  helpdesk  or/and  further  software  upgrades   (Stol  &  Ali  Babar,  2010).  Even  though
increasing  number  of  the  OSS  projects  are  supported  or   driven  by  commercial  organizations
(Ven  &  Manneart,  2010),  they  are  still based more or less  on the work of volunteers. This affects
also   the  outputs  of  the  community  and  project.  Some  certain  shortages  in  OSS  projects  have
created  possibilities  for  new  business  models  in open source and perhaps the most common is
providing  the  support  and  services  for  open  source  products  (Gary,  Koehnemann,  Blankey,
Goar,   Mann  &  Kagan,  2009).  The  success  of  these  kind  of  commercial  activities  shows  that
users of OSS need better support and services that voluntary OSS projects can provide.

Some  open  source  projects  are  suffering  from  the  lack  of  documentation  –  the  quality  of  the
documentation  is  insufficient  or  it  is  missing.  In  some  cases  challenges  are caused  by  several
descriptions  of   the  same  component.  (Stol  &  Ali  Babar,  2010;  Gary,  Koehnemann,  Blankey,
Goar,   Mann  &  Kagan, 2009.)  When  the  documentation is  insufficient  it  might  complicate  or/and
retard  the  development  or  in  the  worst  case  even  hinder  the  work.  The  sparse  documentation
may  not  be  the  only problem in OSS projects. Voluntary basis provided support does not provide
always  helpdesk  or  technical  support  that  users  would  require  and  there  is  not always available
even   commercial  support  (Stol  &  Ali  Babar,  2010).  Thus,  it  is  not  perhaps  surprise  that  OSS
communities  are  primarily   used  by  organizations  with  a  strong  technical  background  (cited  in
Stol & Ali Babar, 2010).

Companies should also include time and resources to the operational plan to perform a variety of
testing  as  many  open  source  projects  do  not  have  a  rigorous  or  formal  testing  process.
Performance,  scalability  and  environmental  issues  such   as  the  various  databases  and  other
 11

platforms  the  product will be required to support should be  tested. (Gary, Koehnemann, Blankey,

Goar, Mann & Kagan, 2009.)

Another   issue  is  uncertainty  about  product’s  future   and   consequences  for  company  if  the  OS
project  is  stopped.  Due  to  voluntary  work  long­term  support  of  OSS   products  is  uncertain  as
some  proprietary  software  companies  have  claimed  (Ågerfalk,  Deverell,  Fitzgerald  &  Lorraine,
2005).   This  may  be  realistic  concern  and  if  the  community  supporting  the  certain  product
disappears  company  may  take  over  the  maintenance  efforts.  However,  this  would  require
additional  maintenance  efforts  and  distract  the  company  from  its  core  business  (Stol  &  Ali
Babar, 2010).

Even  though  open  source  software  is  generally  deemed  secure,  there’s  one  important  security
implication  associated  with  it:  The  engineers  in  charge  of  adopting  an  open  system  cannot  be
sure  that  it  has  been  developed  with  security  in   mind,  that  is,  by  taking  correct  precautions
multiple  times   throughout  development.  This  is  in  contrast   with  in­house  proprietary  systems,
where  care  can  be  taken that the  development  process  follows  security best practices from the
start to the end. (Das, Sarkani & Mazzuchi, 2012)

3. Discussion
Based on both this research and the authors’ personal experiences when working in the field as
professionals and students, the authors suggest that companies take a look into adopting open
source software, but don’t be overly strict about it in either direction. In many cases, open source
software is both less expensive (in terms of acquisition fees, licensing costs and indirect costs)
and of better quality than proprietary software. In others, proprietary software, though initially
more expensive, provides reductions of costs in terms of better productivity of users. In any
case, there are both arguments and counter­arguments for the cost­effectiveness of open
source software (Ven et al. 2008), and the total cost benefits need to be analyzed on a
case­by­case basis when adopting open software.

Companies that currently don’t have an existing system in place should probably be more
weighted towards open source solutions. This reduces both initial costs and the risk from vendor
lock­in (Ven et al. 2008), results in adoption of open standards that are generally more supported
than proprietary ones (Ven et al. 2008), and may result in improved productivity from personnel,
who can install the software on their home systems without problems with licensing fees (Ebert,
2008). On the other hand, migration to open source from an existing proprietary system can get
costly, and needs to be carefully analyzed (Ven et al. 2008).

According to our findings, we found out that quality of open source software is both a strength
 12

and a weakness. It must be noticed that the scope of open source software is very large: some
open source software applications stand out in terms of software quality on all levels, some are
highly usable but lack important things like documentation. We understand that for example
missing or insufficient documentation is a weakness, but it’s not a so called bottleneck, which
would lead to a decision not to use that software.

Software licenses around open source software might cause headaches for businesses, but
they can’t really avoid them. We believe that when companies put focus and learn them at the
beginning of their open source adaptation processes, licenses become a natural part of their
business. If companies don’t pay attention to licenses, that could lead to major issues, which
could lead to the failure of the business as a whole.

We think open source software is very beneficial for technology startups.. Startups benefit from
the initial lower costs of software acquisition and licensing, and don’t usually have huge
proprietary systems already in place that would need to be replaced and migrated away from,
causing switching costs and personnel retraining.  Startups can also begin to use the same
development tools as enterprises right away, i.e., they don’t need to “reinvent the wheel.” Many of
the personnel in technology startups may also generally be of a more technical nature, and as
such may require less training and other support in forms of documentation with the software
they use. That is, many of the weaknesses of open source software adoption are mitigated for
technology startups, and many of the strengths boosted.

From a software developer’s perspective, being an “open source company” also has a positive
ring to it, which might attract new developers to the company. Contributing back to open source
projects might boost a company’s image and gain name for it, resulting in a form of advertising
to developers and customers alike. Based on the authors’ experiences in the field, in many
cases an open source solution is also a requirement for a customer of a company. As such,
having name and experience in the open source community might also boost a company’s
changes in getting new customers and developing useful solutions.

4. Conclusions

The limitation of this study is that the scale of OSS is extremely large, this is just a snapshot
based on the literature we could find. We understand that strengths, weaknesses, opportunities
and threats may even be company specific.

Based on our research there are many strengths when using open source software. The
acquisition cost and licensing fees are very low. This is essential for companies, who are more
and more willing to cut down overall costs. The quality and the security of open source software
is generally considered good. Large developer base, and the inherent openness of the source
 13

code, means that bugs will be fixed when they are found. By having multiple vendors, companies
are not depended on the supply of one single vendor. The general productivity and work climate
around open source software is considered is a strength also.

There are some weaknesses also related to open source software from the viewpoint of
companies. Customizing work may be expected, since some software may not be suitable
out­of­box. Indirect costs might rise above the costs of proprietary software with higher initial
costs. Open source software should be evaluated thoroughly before taking it into use. Surely,
resources are needed when performing evaluation or customization.

The biggest opportunities related to using open source software are new business possibilities.
Dual­licensing is something to be considered for companies: There are good examples
available. The idea of using open source software as a platform is something more and more
companies will be doing in the future, based on the success of Google and Amazon. Also, the
adoption of open standards opens doors for companies when new, compatible services become
available.

We found out that there are also few threats when companies use open source software. The
control over project is a major threat: Disagreements with the project may have crucial effects
on the overall business of company. The lack of vital documentation may bring unexpected
damages to the whole company. The testing of the open source software may not always be
sufficient, scalability and performance related problems might even bring down the infrastructure
of company.

The challenges faced and benefits to be gained by a company when using open source software
depend greatly on the specific company and open source project in question. We suggest that
the companies adopting open source software would carefully consider all the aspects the
article brings out: that there are many strengths to be gained from open source software but that
the total costs of adopting it are not limited to acquisition and licensing costs, that the software
might need to be customized and might not be documented or supported as well, that licensing
issues might be involved and that contributing back to the community might not just happen that
simply. A total cost­benefit analysis, where these issues are taken into account, should be
considered when making large decisions.

Though so, one must also not overcomplicate things: Letting the employees of a company use
the Mozilla Firefox web browser over a proprietary one is a different decision than deciding on the
architecture on which to base the company’s new flagship software product. In many cases,
open source software can be tried out very simply, and one can just switch back to the old ways
without much loss if it doesn’t fit one’s needs.

For future research, we recommend case specific SWOT studies in open source software
environment. One very interesting topic could the world of mobile computing and Android
operating system. We also recommend doing a case study where a researcher can test if our
 14

findings apply in selected companies.

REFERENCES

Audris M, Herbsleb J.D, Roy F: Two Case Studies of Open Source Software Development:
Apache and Mozilla, 2002.

Das, R., Sarkani, S., & Mazzuchi, T. A. (2012, October). Fast Abstract: Software Selection
Based on Quantitative Security Risk Assessment. In High­Assurance Systems Engineering
(HASE), 2012 IEEE 14th International Symposium on (pp. 171­172). IEEE.
ISO 690

Dedrick, J., & West, J. (2004, January). An exploratory study into open source platform adoption.
In System Sciences, 2004. Proceedings of the 37th Annual Hawaii International Conference on
(pp. 10­pp). IEEE.

Dehinbo, K., Pretorius, P., & Dehinbo, J. (2012, April). Strategic Analysis Towards Deriving
Competitive Advantage with the Use of FOSS: The Case of a South African University. In
Information Technology: New Generations (ITNG), 2012 Ninth International Conference on (pp.
335­342). IEEE.

Ebert, C. (2008). Open source software in industry. Software, IEEE, 25(3), 52­53.

Fitzgerald, B. 2006. The Transformation of Open Source Software. MIS Quarterly Vol. 30 No. 3.

Gary, K., Koehnemann, H., Blankey, J., Goar, C., Mann, H., & Kagan, A. (2009). A Case Study:
Open Source Community and the Commercial Enterprise. The Proceedings of 6th International
Conference on Information Technology: New Generations.

Kuhn King, R. (2004). Enhancing SWOT analysis using triz and the bipolar conflict graph: A
case study on the Microsoft Corporation, 2.

Merilinna, J. & Matinlassi, M. (2006). State of the Art and Practice of Open Source Component
Integration. Proceedings of 32nd EUROMICRO Conference on Software Engineering and
 15

Advanced Applications.

Munga, N., Fogwill, T. & Williams, Q. (2009). The Adoption of Open Source Software Business
Models: A Red Hat and IBM Case Study. Annual Research Conference of the South African
Institute of Computer Scientists and Information Techologists (SAICSIT), 112 – 121.

Open Source Initiative, http://opensource.org/docs/osd, October 31, 2013.

Raymond, E. (1999, 1). The cathedral and the bazaar. Knowledge, Technology & Policy, 12(3),
23­49.

Raymond, E. S. (1999, 2). The magic cauldron.

Rigby, P. C., German, D. M., & Storey, M. A. (2008, May). Open source software peer review
practices: a case study of the apache server. In Proceedings of the 30th international conference
on Software engineering (pp. 541­550). ACM.

Scacchi, W. (2007). Free/Open Source Software Development: Recent Research Results and
Emerging Opportunities.Advances in Computers, 69, 243 ­ 295.

Shaikh, M., & Cornford, T. (2010, January). 'Letting go of control' to embrace open source:
implications for company and community. In System Sciences (HICSS), 2010 43rd Hawaii
International Conference on (pp. 1­10). IEEE.

Stol, K­J. & Ali Babar, M. (2010). Challenges in Using Open Source Software in Product
Development: A Review of the Literature. Proceedings of the 3rd International Workshop on
Emerging Trends in Free/Libre/Open Source Software Research and Development.

Ven, K. & Herwig, M. (2007). Challenges and strategies in the use of Open Source Software by
Independent Software Vendors. Information and Software Technology 50(2008), 991–1002.

Ven, K., Verelst, J., & Mannaert, H. (2008). Should you adopt open source software?. Software,
IEEE, 25(3), 54­59.

Weibing Chen, Jingyue Li etc: An Empirical Study on Software Development with Open Source
Components in the Chinese Software Industry. 2007

Ågerfalk, P., Deverell, A., Fitzgerald, B. & Lorraine, M. (2005). Assessing the Role of Open
Source Software Sector: A Voice from Industry. Proceedings of the First International
Conference on Open Source Systems.