Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
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 costbenefit 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
manhours 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 reviewthencommit 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 industrystandard 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
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
duallicensed 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 timeconsuming, 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).
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 timeconsuming 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 longterm 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 valueadded
services in their own business domains. They are not distributing the software itself, so they
don’t have problems of compliance with GPLlicense. (Fitzgerald, 2006)
Open Source Software has given companies opportunities to create new markets and so called
dualproduct strategies. Widely known Red Hat is a common example of the dualproduct
strategy: Red Hat has a free Linuxbased operating system Fedora and they are also offering
Enterprise Linux as a commercial product. The idea behind the dualproduct 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, reinventing 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
Another issue is uncertainty about product’s future and consequences for company if the OS
project is stopped. Due to voluntary work longterm 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 inhouse 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 counterarguments for the costeffectiveness of open
source software (Ven et al. 2008), and the total cost benefits need to be analyzed on a
casebycase 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
lockin (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
outofbox. 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.
Duallicensing 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 costbenefit 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 HighAssurance Systems Engineering
(HASE), 2012 IEEE 14th International Symposium on (pp. 171172). 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. 10pp). 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.
335342). IEEE.
Ebert, C. (2008). Open source software in industry. Software, IEEE, 25(3), 5253.
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),
2349.
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. 541550). 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. 110). IEEE.
Stol, KJ. & 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), 5459.
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.