The document discusses open source business models and factors that influence a company's decision to adopt an open source strategy. It describes three main open source business models: distributor models, software producer models, and third party service provider models. Companies may choose to go open to benefit from community feedback, rapid bug fixing, flexibility, and reduced business risks. While proprietary strategies keep source code private, open source allows anyone to review and improve code quality in exchange for losing control over the code. The document also examines challenges of transitioning from proprietary to open source and the benefits of hybrid models that combine both approaches. It provides examples of JBoss and Zope Europe Association that successfully implemented dynamic open source business strategies.

1. Companies gone open:
adoption and application
of Open­Source Business
Models
Roberto Medico, Alvaro Garcia, Iban Eguía
Abstract
1. Introduction
2. Open­Source Business Models
2.1 Distributor models
2.2 Software producer models
2.3 Third party service provider model
3. Why going open and what to take into account
3.1 Why going open
3.2 Switching from a proprietary strategy
3.3 Entering the market with an OS product
3.4 Hybrid Models
4. Models in action: successful cases
4.1 JBoss: dynamic business model adapting to the market
4.2 Zope and Community­based ZEA
5. Conclusions
1

2. Abstract
This article explores the dynamics of the software distribution market, focusing on open
source (OS) business strategies. After an overview on the main existing business models,
both in the proprietary and open distribution, an analysis of the factors that can possibly
influence the decision to go open is carried out, alongside a critical evaluation of both the
advantages and disadvantages this decision can introduce into a company.
Hybrid models are then presented as a balanced compromise between proprietary and open
business models, followed by a brief guide on how companies can choose the proper degree
of openness for their own business. Finally, JBOSS and ZEA’s successful OS business
models are presented as examples of dynamic strategies that adapt and fit into the market
exploiting OS strengths and advantages.
1. Introduction
The aim of this article is to analyse and discuss the adoption of Open Source business
strategies in the software production (and distribution) market and to compare different
models based on those.
Prior literature has also discussed this topic, especially focusing on OS business models, and
analysing the alternative methods used to get income and revenues (e.g. services offered for
a fee: consulting, support etc.), given that they’re offering free software (Krishnamurthy 2005;
Raymond, 1999). For instance, some of the Open Source models analysed in these
researches are the software distributor models, the software producer models and the third
party service provider models.
Specifically, the research question this article will address is the following: “Which factors and
dynamics can affect the decision of a company to go open in the software production and
distribution market? In particular, when adopting an OS entry strategy or switching from a
proprietary strategy can be a beneficial strategy?”
The research is performed by firstly going through existing proprietary and OS models
discussed in the literature, highlighting advantages and disadvantages, moving on to analyse
the relatively new tendency to adopt hybrid strategies, i.e. mixing open and proprietary
models, finally ending by showing two successful and peculiar cases of the application of
those models, JBOSS and Zope Europe Association (ZEA).
2

3. 2. Open-Source Business Models
Depending on what the enterprise will be offering, we can classify Open­Source business
models, as with private business models, in product­based business models and
services­based business models. As written by Krishnamurthy in 2005, we can see that
service business models are more common between Open Source software than product
business models. Nevertheless, there are some good approaches in the product selling
market using Open Source software (Massey, 2005).
2.1 Product-based models
Product­based business models are the continuation of usual private software business
models, in which the software product itself is being sold and is the one giving profitability to
the company (Krishnamurthy, 2005). There are various implementations of such a business
model in the market, using Open Source software, but there are two main scenarios (Groen,
2012):
● The first scenario, is the one in which the software itself is being based in plenty Open
Source code, and while all that code and company’s contribution is still open, the final
product is kept closed.
● In the second scenario, the software is open sourced, but the distribution media is the
one being sold, giving users a more reliable and simple installation process
(Krishnamurthy, 2005).
For example, we can see that RedHat provides customers with CD versions of the software at
a low cost comparing to other operating systems, even if the software is freely available
(Krishnamurthy, 2005).
3

4. 2.2 Services-based models
As we have seen before, services­based models are the most common models in Open
Source industry. These models are mainly based in offering services related to an open
source software that can be developed mainly by the company itself or the company might be
providing services for other software (Massey, 2005).
As analysed by Krishnamurthy, one of the main markets in this approach is the professional
support for open source software. While the usual example here would be RedHat, there are
more cases, some of them that provide professional support for more than one open source
software, that has nothing to do with the company itself (Groen, 2012). Most of them use to
state a minimum quality requirement the open source product needs to have so that they can
provide such support (Krishnamurthy, 2005).
3. Why going open and what to take into account
Whenever a company decides to go open, there are several factors to take into account to
avoid being overwhelmed by the transition. Nonetheless, this is also true in the case of a new
company deciding to enter the market: is it worth it to offer an OS product? How to evaluate
risks and potentials? The next sections cover both these scenarios and discuss the benefits
and pitfalls of the transition.
3.1 Why going open
Many researches have been carried out about the reasons more and more companies decide
to release software under OS license or to collaborate in OS projects (Chesbrough, 2012).
Between the main reasons, companies seem definitely attracted by the possibility of having a
community around their products: such an ecosystem cannot only guarantee quality through
continuous peer review (Watson, Boudreau, York, Greiner & Wynn, 2008) but also code
reliability and security.
This is especially useful for some specific applications that require extra security and
reliability, as Applewhite (2003) argues. In those cases, open source can be really
advantageous, since it provides a huge peer review based on the possibility for everyone to
review it (Baldwin, 2014).
The second point to review is the need for a rapid bug fixing. While some software can have a
small error not fixed for a long period, in some cases the software needs an extremely quick
patching and releasing, because of its nature. Open source can stand as a good alternative
(Baldwin, 2014) in these cases too, since it enables everyone to submit a fix as soon as it
appears.
4

5.
The third scenario to take into account that could lead a company to adapt a more open
business model would be the need for scalability and flexibility (Chesbrough, 2012). It could
be that the software would be competing in a rapidly changing market, and with only
proprietary contributions, where changes would cost both time and money, while with open
source, it could be assessed much more efficiently, as pointed out by Baldwin (2014).
Another important feature to take into account is that open source software reduces the
business risk in the case of a project being discontinued (Baldwin, 2014). That supposes that
if the software is critical for a company, relying on open source would give it the advantage of
being able to continue its development if the original developer drops his support.
On the same line, open source software usually is more kind of open standards, available for
everyone (Baldwin, 2014), so if the company needs accessibility and cross­platform
standards, it is a feature to take into account, so they can reach to a wider audience.
In the end, what all this points out is that open source software provides quality at a
reasonable cost (Baldwin, 2014) since the company will not need to invest as much as it
would with a proprietary model, but will receive a quality software with a huge peer review
process (Applewhite, 2003).
3.2 Switching from a proprietary strategy
To understand open source business models and the differences with the proprietary ones, so
that companies can decide which path to follow, there is a need to know and understand the
proprietary business models that have been the norm at least until now (Applewhite, 2003).
Proprietary business models are based on the fact that the code remains private, so the
competence will not be able to use it against the company. This means that the code is part of
the intellectual property of the business itself, and it is maintained secret. The final product
might or might not be for free, and that will depend on the business model of the company
(Economides & Katsamakas, 2005).
However, even if those seem really good advantages, this model also shows some
drawbacks: the code is only reviewed by in­company developers. This means that there is
less people available to make the code secure and efficient. The company itself only makes
all the testing and work, so the imagination gets cut off (Baldwin, 2014).
Speaking about the transition to an OS model from a proprietary strategy, clearly the first
thing a company has to understand and quietly accept is the loss of any income coming from
software distribution: since OS licences are free to use and redistribute, users are not
required to pay anymore for the software itself (West, 2003). In addition, giving away the
software through an OS license means that everyone can consult and use the source code,
5

6. including the company’s competitors, possibly giving them crucial advantages. So, back to our
research question, how to find out if the transition from a well­established proprietary strategy
to a new and possibly risky business like an open source model will be beneficial for a
company?
Of course, there is no direct answer to this question but an adequate estimated answer can
be found by analysing benefits and disadvantages that an OS strategy could introduce.
Besides the reasons discussed in the previous section, one of the main benefit particularly felt
from a previously proprietary business model is that an OS strategy could enhance and
facilitate the tendency to innovation of the products (Economides et al., 2005), taking
advantage of the ambition and motivation of the users­programmers within the community
around an open source product. This concept is also referred to as open innovation paradigm
(West & Gallagher, 2006) where the authors point out how it strongly clashes with the typical
vertical integration system proposed by proprietary distribution, where internal research
activities, despite being promising, are often left behind and not developed further because of
the lack of an external source for innovation, such as a community of motivated programmers.
Of course, to make open innovation productive for the business and not only an advantage to
possible competitors by unveiling own technologies, firms should exploit both internal and
external innovation introduced by the adoption of an open source business model.
This high reliability and robustness (Krishnamurthy, 2005) obtained by wide communities
(ecosystems) of debuggers goes along with the possibility to get complementary assets
improving the product from third party companies collaborating in the project (West, 2003).
Better flexibility to the (expert) user and the continuous and widespread support provided by
the OS communities should also be considered as important advantages of adopting an OS
business model (Krishnamurthy, 2005).
On the other hand, expenses and pitfalls must also be taken into account. One of the main
expenses comes from the switching costs, deriving from issues like compatibility of hardware
and software and handling different generations of a software (Bonaccorsi, Giannangeli &
Rossi, 2006). Proprietary companies who decide to switch a software to an OS model can
have trouble to make the product backlog gained during the years compatible, and these
difficulties are harder the longer the company has been into a proprietary model. Costs can
derive also from demand if the transition to an OS product requires the developers or the
end­users to be additionally trained. Technical disadvantages can also derive from the version
proliferation typically present around an OS product and the poor (or at least worse) usability
(Krishnamurthy, 2005). In general, adopting a new open model trying to calmly replace an
existing one is a challenging task, and usually companies tend to make the two different
models coexist in some way (Chesbrough, 2012), adopting a kind of hybrid strategy.
Beside the decision of going open, another critical point is to choose the degree of openness
a company should adopt; in other words, it is necessary to understand when the decision of
going open is actually going to be an improvement for the business of a company. It is
possible to find some direct factors that can limit the degree of openness as well as factors
that make it profitable to enhance it (Bonaccorsi et al., 2006).
6

7. According to West (2003), the degree of openness should be evaluated against the
community of users a product can address: going open should provide substantial benefits for
more than a niche of expert users.
One of the most influential factor in this decision though is the experience in this field (e.g. the
involvement in OS community projects) rather than the motivation or belief in OS principles of
the company’s owner (Bonaccorsi et al., 2006).
Understanding how this transition will affect the company can be a challenging task and
several factors (e.g. company’s internal organization, company’s activity period, company’s
leaders devotion to OS mind­set and so on) can actually slow it down or make it faster
(Bonaccorsi et al., 2006).
The table below summarizes the benefits and pitfalls discussed in this section:
Benefits Pitfalls
Innovation Compatibility issues with existing
infrastructures
Code reliability and security (additional) training expenses
Quality assurance Version proliferation
Scalability and flexibility Poorer usability
Protection against business risks Loss of direct incomes
Possibly larger audience (open
standards)
7

8. 3.3 Entering the market with an OS product
What about a new company entering the market with a new product? Which pitfalls there can
be given that there are no switching or training additional expenses? Moreover, when an open
source strategy can lead to a more beneficial business than a standard proprietary model
where income is guaranteed by the selling of the product?
If the decision is to go open, there are two feature of the product to be analysed to evaluate
which is the profit potential of it: customer applicability and relative product importance. The
former identifies the amount of people who would potentially use and benefit from the product,
while the latter measures how relevant and useful the product is for users (Krishnamurthy,
2005). Depending on these two features, the author proposes a taxonomy consisting of four
different categories of product, with increasing profit potential: stars, high­profile nichers,
mainstream utilities, low­profile nichers.
Once identified the category the product belongs to, other factors can still affect the profit;
firstly, the primary developer community: if this is a motivated and united team willing to
continuously innovate and improve, the product will benefit mostly both in distribution and
user­satisfaction. On the other hand, the presence of other dominant OSS products in the
same field can negatively affect the success of the product, because competition between OS
products is fierce and challenging, both on the product category and distribution level. In
addition to this, there could be also proprietary competitors with products in the same field: in
this case, competition can even be harder because of the bigger amount of resources (e.g. in
advertising, marketing etc.) that a commercial business can guarantee. Still, if the product is
innovative and provides useful services, it can be competitive if supported with an adequate
marketing campaign.
3.4 Hybrid Models
The prospect of a pure open source model can be seen as too risky by some companies,
which would like to take advantage of the benefits it provides still without losing the stability
and incomes coming from a proprietary strategy. In this context, it seems an effective and
convenient idea that of mixing the freedom and the communitarian ideas behind an open
distribution with the guarantee of incomes and stability of a proprietary one, adopting one of
the so­called hybrid models (Bonaccorsi et al., 2006). As previously seen, many open source
business models relies on other sources of income offering several OS­related services such
as consulting, supporting, sponsorships etc.
It’s interesting to notice that these hybrid models are gathering more and more attention in the
recent years (Chesbrough, 2012; West, 2003) and that they don’t seem to stand up as a
transitional state between pure proprietary models to pure OS ones but instead they are
reliable and stable strategies able to adapt and follow the dynamics of the market (Bonaccorsi
8

9. et al., 2006). According to the authors’ research, the transition is never an irreversible
process, as “firms may calibrate their openness to it with respect to their customer base and
maintain a mixed product and service portfolio”.
According to West (2003), two are the main hybrid strategies used:
● Opening parts, that is disclosing (i.e. releasing under an OS license) only some layers
of a product while keeping hidden others (possibly the most useful);
● Partly open, that is releasing the product under such restrictions that it remains usable
but very hard to be integrated by competitors.
The analysis conducted shows how many companies today have adopted these hybrid
strategies to play a leading role in the market: the effects and the outcome strongly depend on
a company’s ability to calibrate properly their openness and to make customers collaborate
into software production, so that marginal costs for customizing, updating and improving the
software are significantly lower. The next section will discuss how a company can decide and
set its degree of openness, that is how many and which open services to offer.
4. Models in action: successful cases
The purpose of this section of the paper is to show how business models based on Open
Source can work in a real competitive environment through case studies, which consist on the
analysis, using information collected from many different sources, of an event in its natural
emplacement. The information collected in our review so far will be used as the framework to
analyse the study cases.
Companies turn to open source to reduce their costs while developing and maintaining and to
focus better their efforts on points that make them different from their competitors. (Weiss,
2011).
In terms of Open Source business models the most common study cases are those about
RedHat and IBM (Munga, Fogwill, & Williams, 2009). In order to show other successful cases
that used different strategies, the next sections will focus on the adoption of open source
business models in two different enterprises. The first study case examines JBoss, a
company that applied the professional open source (POS) business model. JBoss is property
of Red Hat since 2006, after they firstly applied the POS business model. The second study
case examines Zope Europe Association (ZEA), which adopted an open source business
model based on network.
9

10. 4.1 JBoss: dynamic business model adapting to the market
JBoss started as a failed '.com' company at the beginning of the XXI century and turned to be
leader in the Java application server market. This change was possible thanks to the adoption
of the Professional Open Source (POS) business model. JBoss was one of the first
enterprises applying this model; that’s why they are also known as the evangelists of the
POS. POS mixes the benefits provided by the Open Source (OS) with the techniques and
methodologies used by enterprises which work in the software business. The POS model is
based on offering a free­licensed software while offering at the same time maintenance and
support services for a fee (Montalbano, 2006).
When JBoss was created in 1999 it was created applying the Application Service Provider
(ASP) business model. The principal purpose of the company was to create software for
companies to run their server application outside their own servers. Income came because
companies had to pay a charge for using the JBoss framework to develop their applications.
In late 2000, when the bubble of the ‘.com’ enterprises burst, the company was out of
business because even though their product was really valuable, they were not able to get
profit from it (Watson, Wynn, & Boudreau, 2005).
JBoss offered a more reliable application to work with because many tasks performed with the
software were critical. When a client enterprise found a problem, it tried to make use of their
employees to solve it as fast as possible but when that was not possible, they had to contact
an expert. Open Source model provided many ways to find this kind of experts such as
communities. Experts who were part of the communities had another way of working different
from the ones who were hired by JBoss; they went a step ahead because they were
motivated, they were not obliged to work for an amount of money as hired employees did
(Raymond, 1999). In communities, developers or even staff of an enterprise could receive
answers to their questions by users with some expertise in the product for free. Many of the
people who were in forums were later hired by JBoss to provide paid 24x7 support to those
enterprises, which used the software for critical tasks. That support was given by an assigned
employee avoiding the necessity to talk with many persons to solve a single problem (Watson
et al., 2005). That was an advantage compared to other enterprises of the sector because
even though having a large community results into a quick response or solution to problems,
those who were paying for support, only had to talk with an expert to receive the solution
making the task quicker which is a determinant factor when dealing with critical tasks.
Having an active community behind JBoss also helped to find more bugs and solve them
quicker than before. Developers who were using the application could use forums or
communities to tell about bugs found and other participants could solve those bugs in the
source code. In words of Raymond (1999), the more eyes you have in the code, the more
bugs appear. These communities also give a quicker solution to those bugs compared to
classical models. Communities can be helpful for end­users but also for software producers,
10

11. because they can see users’ contributions made and hire them in the enterprise to use their
expertise also in paid­services.
Having a quality code requires to invest money and the financial situation of JBoss before
taking the POS model did not allow that. According to Golden (2005), the quality of JBoss is
quite good and he has completed a big amount of tests (more than 16,000) obtaining a good
result from them. The good results obtained from tests came from two different sides: OS
contributors and JBoss product team. Contributors from the community were able to write
code but not all the code written by these contributors was valid, as it happens in many OS
projects, the code should follow some coding styles, some quality requirements and cover the
principles of JEMS (JBoss Developer, 2007). For those who were contributing for their first
time JBoss provided a guide with the steps to follow and the requirements to follow. Apart
from contributors, JBoss also had a production team, which was very large taking into account
that it was an OS project. Having a large developer group is essential to develop a quality
code (Raymond, 1999). In that production team, there were about 91 engineers (Golden,
2005). From those 91 engineers, many of them worked checking and validating the
contributions made from the community, and about 12 of them were constantly checking the
source code.
To conclude with this study case we can say that the model worked very well from the
beginning: JBoss adopted this model in 2001 when it was out of business and 5 years later, in
2006, the company was sold to RedHat for $350 million (LaMonica, 2006). JBoss was one of
the first enterprises adopting the POS business model and because of the great outcome it is
often taken as an example to follow while implementing this business model.
4.2 Zope and Community-based ZEA
Zope Europe Association (ZEA) is a business network with presence in many countries all
over the world. ZEA builds software and makes business with a server application called
Zope. Zope is an open source application written in Python and published under the Zope
public license. Zope is used to create applications like intranets or web portals using an object
oriented web application server. Companies like ZEA, also known as virtual companies apply
to the network business model with the aim to deliver a 'whole product' (Feller, Finnegan,
Fitzgerald, & Hayes, 2008).
Everything started in 2003 when Zope and Plone decided to work together and they created
the Zope Europe Association, which was renamed in 2006 to ZEA partners. As the software
was published on the web and the code was available, many developers started to maintain
and develop the code that lead to the creation of virtual communities (Soekijad & De Joodel,
2011).
Companies that participate in this network usually are not big enough to compete in the
market by their own because they usually have about ten employees. A small company of
11

12. about 10 employees can innovate up to a point. The innovation for these enterprises comes
when many of them work together in a large project and share their knowledge and way of
working with the network. That was what happened with ZEA. Each enterprise that
participated in the network had its way of working and made use of certain technologies but
having more enterprises to collaborate helped the exchange of knowledge, adoption of new
technologies and exchange of ideas for future projects. All this resulted into innovations in
future developments that could not have happened if the enterprises had not joined this
network model and worked together as one. At the end, the application of the model in those
small enterprises made the network more innovative and along that, the products developed
by it as well. This capacity of innovation could be also seen when a customer was asking for a
specific feature to one of the participants of the network. Differently from a classical
enterprise, participants of the network were free to work in a project on their own even if the
network did not approve it; the capacity of adaptation was also highly improved (Feller,
Finnegan, & Hayes, 2006). That obtained capacity of adaptation was highly determined by
how the enterprises of the network were configured (Somuyima, Adebayo, & Akanbi, 2011).
Another benefit obtained after applying the network model was the reduction on the time while
fixing bugs. As said before, participants of the network were sharing their information and their
knowledge while working together. The same philosophy was adopted to deal with bugs. The
network model takes from the OS communities the use of IT infrastructures, which were more
focused on interactive transactions instead of transactional ones (Feller et al., 2008).
Participants of ZEA had a common methodology to assign the work, to think about a concrete
problem or even to report and track bugs. This resulted in a reduction on the time needed to
find and solve a bug (Feller et al., 2006). To facilitate the intercommunication between the
participants in the network they made use of mailing lists and organized regular meeting that
were not available only for partners, but open for everyone to join (Soekijad & De Joodel,
2011).
The network also brought higher quality in the code. Not all software companies were suitable
to participate in the network. Before joining ZEA participants had to be leaders in the market
on their speciality. Participating in a network like ZEA also implied to work in a competent way
because the reputation of the network was on the hand of each participant. If a participant
was not working in a proper way, it can be banned from the project or even from the network
(Feller et al., 2008). All this resulted in a code with more quality and the fact that the costs of
the network were shared between all the participants made the costs quite reasonable.
Before taking part in the network, participants were using classical techniques. After the
application of the network model, those classical techniques turned to be agile techniques
(Feller et al., 2006). Those agile techniques and the lack of a scheduled timetable made the
network more flexible than it was before.
As a conclusion, we can say that having an effective implementation of the network business
model requires to maintain a productive relation between enterprises that are part of the
12

13. network, exchange resources and perform a good work with clients avoiding all possible
errors not to affect to the image of the whole brand (Feller et al., 2008).
5. Conclusions
The research carried out in this article shows that the adoption of OS business models can be
a viable commercial option for companies and also stand as a profitable strategy to be
competitive in an ever changing market: both proprietary and open models can be mixed
together to create the best strategy according to the current situation of the market. As
explained throughout the article, more and more companies are switching to OS business
models or at least include some OS projects to obtain the benefits they can offer: quality and
variety of the services, guaranteed by fast and continuous innovation within an active and
collaborative community.
As for our research questions, we have seen how several requirements (desire for innovation,
quality and security of the code assurance, wider audience, etc.) could act as motivating
reasons to adopt some Open­Source business model as well as potential pitfalls and
expenses (switching costs, organizational changes, compatibility issues etc.) that could act as
deterrents.
Moreover, the study cases proposed have shown how the companies using open models can
adapt and change them according to the current needs, exploiting their flexibility to follow the
changing dynamics in the market (customers’ needs, competitors’ pressure, companies’
networks etc.)
Nonetheless, this literature review can only offer general guidelines and an overview on the
market situation and the business models used, without the aim to offer a silver bullet for a
company. There is no such thing as global rules to follow to become successful, and the
strategy should be chosen case by case, according to the types of services offered, the
targeted market and the competitive environment.
Since the topics covered in this review are quite recent and focus on a dynamic environment
like that of software production and distribution, future researches about them could use this
article as a starting point, taking into account the business strategies showed here while being
aware of the possible evolution of companies and the rise of new hybrid approaches in the
meantime that could be adopted in this environment.
13

14. References
Applewhite, A. (2003). Should governments go open source?. Software, IEEE, 20(4), 88­91.
Bonaccorsi, A., Giannangeli, S., & Rossi, C. (2006). Entry strategies under competing
standards: Hybrid business models in the open source software industry. Management
Science, 52(7), 1085­1098.
Chesbrough, H. (2012). Why companies should have open business models. MIT Sloan
management review, 48(2).
Economides, N., & Katsamakas, E. (2005). Linux vs. Windows: A comparison of application
and platform innovation incentives for open source and proprietary software platforms. New
York University Law and Economics Working Papers, 32.
http://lsr.nellco.org/cgi/viewcontent.cgi?article=1035&context=nyu_lewp
Feller, J., Finnegan, P., Fitzgerald, B., & Hayes, J. (2008). From peer production to
productization: A study of socially enabled business exchanges in open source service
networks. Information Systems Research, 19(4), 475493.
Feller, J., Finnegan, P., & Hayes, J. (2006). Open source networks: an exploration of
business model and agility issues.
Groen P. , (2012, December 23). Open Source Business Models ­ A More In Depth View
Krishnamurthy, S. (2005). An analysis of open source business models. Perspectives on free
and open source software, 279­296.
LaMonica, M., CNET News (2006, April 10). Red Hat scoops up JBoss. Retrieved from
http://news.cnet.com/Red­Hat­scoops­up­JBoss/2100­7344_3­6059293.html
Massey, B., IEEE Software (2005, October 31). Open Source Business Models: Ready for
Prime Time.
Montalbano, E. (2006, February 16). OBSC: Professional open source grows up. Retrieved
from
http://www.infoworld.com/
Munga, N., Fogwill, T., & Williams, Q. (2009, October). The adoption of open source software
in business models: a Red Hat and IBM case study. In Proceedings of the 2009 Annual
Research Conference of the South African Institute of Computer Scientists and Information
14

15. Technologists (pp. 112121). ACM. Retrieved from
http://researchspace.csir.co.za/dspace/bitstream/10204/3879/1/Munga1_2009.pdf
Raymond, E. (1999). The cathedral and the bazaar. Knowledge, Technology & Policy, 12(3),
23­49.
Raymond, E. S. (1999). The magic cauldron.
Somuyiwa, A. O., Adebayo, I. T., Akanbi, T. A. (2011). Supply Chain Performance: An Agile
Supply Chain Driven By Information System (Is) Capabilities. British Journal of Arts and
Social Sciences, ISSN:20469578,
Vol.I No.2 (2011). Retrieved from
http://www.bjournal.co.uk/paper/BJASS_1_2/BJASS_01_02_06.pdf
Soekijad, M., & De Joodel, W. (2011). Co­opetition in Knowledge Intensive Networks: Two
Case Studies.
Watson, R. T., Boudreau, M. C., York, P. T., Greiner, M. E., & Wynn Jr, D. (2008). The
business of open source. Communications of the ACM, 51(4), 4146.
Watson, R. T., Wynn, D., & Boudreau, M. C. (2005). JBoss: The evolution of professional
open source software. MIS Quarterly Executive, 4(3), 329­341.
Weiss, M. (2011). Company­led open source, International Open and User Innovation
Workshop (OUI), Vienna, Austria
West, J. (2003). How open is open enough?: Melding proprietary and open source platform
strategies. Research policy, 32(7), 1259­1285.
West, J., & Gallagher, S. (2006). Challenges of open innovation: the paradox of firm
investment in open‐source software. R&D Management, 36(3), 319­331.
WEBSITES
4 reasons companies say yes to open source. (2014, January 6). Retrieved from
http://www.computerworld.com/article/2486991/app­development­4­reasons­companies­say­y
es­to­open­source.html
Open Source Business Models (P2P Foundation). Retrieved from
http://p2pfoundation.net/Open_Source_Business_Models
JBoss Developer. (2007). How To Contribute. Retrieved from
https://developer.jboss.org/wiki/HowToContribute?_sscc=t
15

16.
16