How to Successfully Develop and Manage Open Source

How to Successfully Develop
and Manage Open Source Projects
PEDRAM
JOHN
FOROUTAN
Master of Science Thesis
Stockholm, Sweden 2012
How to Successfully Develop
and Manage Open Source Projects
PEDRAM
JOHN
FOROUTAN
2D1021, Master’s Thesis in Computer Science (30 ECTS credits)
Degree Progr. in Computer Science and Engineering 300 credits
Royal Institute of Technology year 2012
Supervisor at CSC was Stefan Arnborg
Examiner was Stefan Arnborg
TRITA-CSC-E 2012:012
ISRN-KTH/CSC/E--12/012--SE
ISSN-1653-5715
Royal Institute of Technology
School of Computer Science and Communication
KTH CSC
SE-100 44 Stockholm, Sweden
URL: www.kth.se/csc
Abstract
The fast growing Open source development methodology has recently become more popular as more
and more software developers and corporations are utilizing and developing Open source software. It
is commonly known that Open source enables development possibilities that are restricted in the
production of proprietary software (i.e. Closed source). A big difference between the two approaches
is the Open source licenses, which allow software creators to manage the restrictiveness of distribution
and third-party development rights. Although Open source offers these valuable tools, many of the
projects encounter difficulties that ultimately lead to their failure. This thesis focuses on identifying
the risks of Open source projects in the fields of development and licensing while also offering
suitable methods that can either prevent or minimize the damage inflicted by them.
Hur man framgångsrikt utvecklar
och driver Open source-projekt
Sammanfattning
Den snabbt växande Open source metodiken har nyligen blivit mer populär eftersom fler och fler
människor och företag är benägna att använda och utveckla öppen källkod. Det är allmänt känt att
Open source ger utvecklingsmöjligheter som är begränsade i produktionen av proprietär programvara
(d.v.s. Closed source). En stor skillnad mellan de två metoderna är Open Source-licenser, som gör att
utvecklarna kan hantera restriktiviteten gällande distribution och tredjepartsutveckling. Även om Open
source erbjuder dessa värdefulla verktyg, stöter många av projekten på svårigheter som leder till
misslyckande. Den här avhandlingen fokuserar på att identifiera riskerna med Open source-projekt
inom utveckling och licensiering samtidigt som den erbjuder lämpliga metoder som antingen kan
förhindra eller minimera skadorna av dem.
Acknowledgements
I would like to thank the Royal Institute of Technology (KTH) and the Florida State University (FSU)
for giving me the opportunity to carry out the final piece of my Masters degree in USA. This thesis
would not have been possible if not for my two advisors, Prof. Stefan Arnborg at KTH and Dr. Robert
van Engelen at FSU. Their invaluable expertise and guidance has been my greatest asset in
constructing this paper. Finally, many thanks to parents and my sister, Dr. Parastou Foroutan, whom
have spent hours in helping me succeed.
Table of Contents
1. Introduction ......................................................................................................................................... 1
2. Background ......................................................................................................................................... 2
2.1 The Open Source Definition.......................................................................................................... 3
2.1.1 Free redistribution .................................................................................................................. 3
2.1.2 Source code ............................................................................................................................ 3
2.1.3 Derived works ........................................................................................................................ 4
2.1.4 Integrity of the author's source code ....................................................................................... 4
2.1.5 No discrimination against persons or groups ......................................................................... 4
2.1.6 No discrimination against fields of endeavor ......................................................................... 4
2.1.7 Distribution of license ............................................................................................................ 4
2.1.8 License must not be specific to a product............................................................................... 5
2.1.9 License must not restrict other software ................................................................................. 5
2.1.10 License must be technology-neutral ..................................................................................... 5
2.2 Open source versus Closed source ................................................................................................ 5
2.3 Problem ......................................................................................................................................... 7
2.4 Purpose .......................................................................................................................................... 7
3. Development and Management of Open source.................................................................................. 8
3.1 Methods analysis ........................................................................................................................... 9
3.2 Methods recommendations.......................................................................................................... 10
3.3 Failure analysis ............................................................................................................................ 11
3.3.1 Costs ..................................................................................................................................... 11
3.3.2 Attraction .............................................................................................................................. 12
3.3.3 Motivation ............................................................................................................................ 12
3.4 Recommendations ....................................................................................................................... 15
3.4.1 Cost....................................................................................................................................... 15
3.4.2 Attraction .............................................................................................................................. 17
3.4.3 Motivation ............................................................................................................................ 18
4. Licensing ........................................................................................................................................... 21
4.1 License traits................................................................................................................................ 22
4.2 Choosing license.......................................................................................................................... 24
4.3 Recommendations ....................................................................................................................... 25
5. Scenarios ........................................................................................................................................... 27
5.1 Scenario 1: Linux and GPL ......................................................................................................... 27
5.1.1 The Red Hat license depending business model .................................................................. 28
5.2 Scenario 2: gSOAP and GPL ...................................................................................................... 29
5.2.1 The gSOAP Multi-licensing business model........................................................................ 29
5.3 Scenarios conclusion ................................................................................................................... 30
6. Conclusion ......................................................................................................................................... 32
References ............................................................................................................................................. 33
1. Introduction
In recent years, the fields of information technology (IT) and computers have seen an important
change. A change that, from some perspectives, is seen as freedom and evolution, while others
perceive it as oppression and “de-emphasizing” of the individual human [1]. A change that has been
practiced with both the oldest and the newest software. A change called Open source, a new way of
organizing production and dissemination of software.
Open source is described commonly as an approach that promotes access to the source code of
software. Moreover, it is seen as a method that helps solve problems through an open collaborative
environment. In recent years, it has received immense amount of attention, primarily from
corporations and individuals who are attempting to make their business and development process more
efficient. Nonetheless, the successful implementation of Open source may be a challenge for many,
and in the worst case could lead to the demise of a project.
This thesis was conducted in collaboration between the Royal Institute of Technology (KTH),
Sweden, and the Florida State University (FSU), USA, where the majority of the research was
performed. Project supervisors were Dr. Robert van Engelen (FSU) and Professor Stefan Arnborg
(KTH). The research is based mainly on journal and conference articles that may be found on the
IEEE Xplore digital library as well as additional information, digital books and examples from various
Internet websites. Furthermore, the software gSOAP, created and owned by Dr. van Engelen, was
reviewed and discussed through personal communication, which resulted in one of the two scenarios
towards the end of this thesis.
The aim of this thesis is to identify the risks of Open source in the problematic areas of development
and licensing as well as suggesting guidelines on how to successfully avoid or overcome them. In
order to address this aim, readers are at first introduced to background information with the purpose to
gain a better understanding of the definition of Open source. Subsequently, this thesis offers
recommendations, based on analysis of the fields development and licensing. In addition, to better
distinguish between these two fields and demonstrate some real-life examples, two scenarios have
been presented in the licensing section. At last, the final conclusions of this work, which includes
procedures and advice on creating successful Open source projects, are presented in the conclusion
section.
1
2. Background
Although Open source is one of the most debated topics of software and software development today,
the actual concept itself is not new. In fact, the development methods of Open source were used as
early as in the beginning of the computer era [2]. For instance, in 1961 a group of PDP-1 computer
users created the program library DECUS (the Digital Equipment Computer Users Society), which had
a structure and functionality that were much like the current Open source communities [3]. At that
point in time, most companies believed that the largest monetary benefits would be gained through the
development of superior hardware, which in turn caused the software to be lacking in terms of quality
and in fulfilling customer demands. In addition, many of the early computer users were knowledgeable
in the field of technology and were often able to adjust the software themselves. Occasionally, the
modified software was sent back to the companies and distributed to other users, allowing them to take
advantage of the implemented changes. In many cases the original creator saw this kind of process as
positive; the end result was improved software that attracted more buyers, thus benefitting not only the
original creators but also the users [4].
While the general opinion of Open source was positive at this early time point, it was not as easy to
implement as it is today. The main reason for this was that the sharing process had to be done by
sending magnetic tapes by surface mail, since there was no Internet [4, 5]. Nevertheless, there were
local networks that made it possible for a small number of developers to share their code, but in
resemblance to the current possibilities, Open source was very restricted. Ironically, in the 1970s, just
when the technical aspects were improved and the tools for successful Open source were actualized,
the general business ethics for computer software changed [6-8]. It became evident that by selling
software separately, high profits could be made. Richard Stallman, the founder of the GNU project,
who was actively working with cooperating communities during the time of change of software
business ethics, describes that the first step was to promise not to help your neighbor. He states that the
law made by the manufacturers of proprietary software was [9]:
“If you share with your neighbor, you are a pirate. If you want any changes,
beg us to make them”
The mentality behind the proprietary software community was clearly not shared by everyone. There
were many more people like Stallman that did not believe that the idea of proprietary software was in
the best interest of the general software progression. One of them was Eric Raymond, who would
become the first president of the Open Source Initiative (OSI).
2
In 1997, Eric Raymond published the paper The Cathedral and The Bazaar. With this paper, Raymond
succeeded to open a new way of understanding the “Hacker” community. The ideas presented in the
paper had a, unexpected, strong appeal outside the “Free software” culture. Raymond followed the
release of his paper with a presentation, at the O'Reilly Perl Conference in September 1997, which
would help trigger the Internet browser Netscape’s decision to open their source code to the public
[10]. It was the events that came with the beginning of proprietary software, such as the GNU project,
combined with the unexpected event regarding Netscape, acting as the trigger, that would lead to the
creation of the OSI. The OSI established, from the Debian Free Software Guidelines, what would
become the platform for the current Open source development, the Open Source Definition (OSD)
[11].
2.1 The Open Source Definition
Generally, “Open source” refers to software or scripts in which the source code is accessible to the
public for use or modification without any costs for intellectual property [12, 13]. It is a fair statement
that has been widely accepted, but, according to the OSI, it is not enough for bearing the title “Open
source software”. They declare, just because software has accessible source code it does not make it
Open source. To prevent exploitation of the term Open source, the OSI created criteria, the OSD,
which do not just concern the source code, but also the distribution and licensing terms. Open source
software must abide by these rules [14]:
2.1.1 Free redistribution
The license shall not restrict any party from selling or giving away the software as a component of an
aggregate software distribution containing programs from several different sources. The license shall
not require a royalty or other fee for such distribution.
2.1.2 Source code
The program must include source code, and must allow distribution in source code as well as compiled
form. Where some form of a product is not distributed with source code, there must be a wellpublicized means of obtaining the source code for no more than a reasonable reproduction cost,
preferably downloading via the Internet without charge. The source code must be the preferred form in
3
which a programmer would modify the program. Deliberately obfuscated source code is not allowed.
Intermediate forms such as the output of a preprocessor or translator are not allowed.
2.1.3 Derived works
The license must allow modifications and derived works1, and must allow them to be distributed under
the same terms as the license of the original software.
2.1.4 Integrity of the author's source code
The license may restrict source-code from being distributed in modified form only if the license allows
the distribution of "patch files" with the source code for the purpose of modifying the program at build
time. The license must explicitly permit distribution of software built from modified source code. The
license may require derived works to carry a different name or version number from the original
software.
2.1.5 No discrimination against persons or groups
The license must not discriminate against any person or group of persons.
2.1.6 No discrimination against fields of endeavor
The license must not restrict anyone from making use of the program in a specific field of endeavor.
For example, it may not restrict the program from being used in a business, or from being used for
genetic or military research. The legality of application should be regulated in national and
international law, not in licensing.
2.1.7 Distribution of license
The rights attached to the program must apply to all to whom the program is redistributed without the
need for execution of an additional license by those parties.
1
Derived works refers mainly to software that includes parts of the original software.
4
2.1.8 License must not be specific to a product
The rights attached to the program must not depend on the program being part of a particular software
distribution. If the program is extracted from that distribution and used or distributed within the terms
of the program's license, all parties to whom the program is redistributed should have the same rights
as those that are granted in conjunction with the original software distribution.
2.1.9 License must not restrict other software
The license must not place restrictions on other software that is distributed along with the licensed
software. For example, the license must not insist that all other programs distributed on the same
medium must be open-source software.
2.1.10 License must be technology-neutral
No provision of the license may be predicated on any individual technology or style of interface.
2.2 Open source versus Closed source
At present, the two main types of software are Open source and Closed source. It is true that Open
source as a model for development is the most recent considering these two types and, as with most
objects and methods, newer often is better. However, both of the models have respective advantages
and disadvantages (Table 1), as well as a history of successes and failures; with the most obvious
advantages being, the speed in which Open source software release greater versions of software, and
the big profits obtainable by Closed source software [2].
The frequent development of Open source software is a consequence of the fast identification of user
requirements. In successful cases, the software attracts many developers, who often are users of the
software, which gives faster requirements identification than in projects in which the developers are
not typical users [15]. This trait is only given in Open source, since the openness gives the user the
opportunity to become a developer.
Profits made by producing Closed source software need no introduction. The manufacturer of the
software can sell it at prices attracting buyers and high profits can be made for a competitive product.
5
One of the difficulties that is derived from this kind of software is that the developers are often few, in
comparison to Open source, and that the cost of making profit is taken from other aspects, such as: less
quality oriented software with lower reliability and stability [16, 17]. Many of the common problems
in Closed source can be solved in Open source. Nonetheless, contrary to what many believe,
developing and managing an Open source project has been proven as complicated, if not more so, than
for a Closed source project.
Table 1. Properties of Open source versus Closed source. Recreated:
A. Khanjani, R. Sulaiman. The Aspects of Choosing Open Source versus Closed Source, pp 648. [2]
Type
Closed Source
Open Source
Free Software
No
Yes
Modify Code by Users
No
Yes
Systematic Development
Yes
No
Frequent Release
No
Yes
Openness
No
Yes
Parallel Process
No
Yes
Knowledge Sharing
No
Yes
Private License
Yes
No
Yes
No
Property
Gaining Profit by
Company
6
2.3 Problem
Many of the issues of Open source are caused by general misunderstandings and lack of respect for the
fast growing approach. It is not that people do not know what Open source is, but rather how extensive
and demanding it can be. Specifically, Open source is often perceived as a concept that requires
software source code to be made open (i.e. available) for users and as a methodology that affects
software progress positively. However, the development of Open source projects is different from
Closed source, and involves the essential step of choosing license, which also influences the use of the
software. Open source is not an extension of Closed source and therefore should not be treated as
such.
Open source development often fails due to negligence of factors that have a high potential of
inflicting severe damage to the project. These factors may be, but are not limited to, a realistic
assessment of costs and inability to attract and motivate developers.
The licensing segment of Open source is one of the most problematic areas. The decision of what
license to choose is complex and must be done after considering many aspects that are not just limited
to the software properties, but also the developer and business model. Moreover, licenses can have
important legal role as the common disregard for the boundaries set by them can end up in expensive
law suits.
2.4 Purpose
The purpose of this thesis is to present guidelines on how to successfully develop and manage Open
source projects by analyzing the risks in the areas of development and licensing. This thesis is an
informative tool that is intended for all types of developers, but is foremost focused on developers and
corporations that are making the transition from Closed source to Open source development.
In addition to developers, the licensing section also includes valuable information for anyone that
seeks to solely use Open source programs. Licensing is required but licensing choices can be
controversial, thus it is important that developers implement licenses properly, and that users choose
licensed software wisely, in order to favor prosperity of the project or business.
Therefore, the scope of this research is on evaluating the most suitable methods in accordance with
theory and practice, rather than presenting and discussing all of the methods that currently exist. These
methods are reviewed and presented in the thesis, and will with certainty be an aid in Open source
projects.
7
3. Development and Management of Open source
There is a statement that follows every article, book, or course about development and management of
software; that is, software development is hard. Regardless of the type of software project (i.e. Closed
source, Free software or Open source), the one constant that characterizes all project description, is
that problems occur during the development of software. In some cases the project manager and the
team manage to overcome these issues and create operating programs, and in other cases they fail in
rising above their difficulties.
The worst outcome in software development is when a project is forced to shut down or is terminated.
In correct terminology, these projects are considered to be failures2. It is a known fact that many
projects in commercial software development have failed and continue to do so still, and even though
Open source has grown to be a popular approach, the failure rate has not improved with the new
methodology. In reality, only a small percentage of Open source projects are considered to be
successful [18, 19]. According to K. Fogel (2009), the failure rate for Open source projects is as high
as 90-95%, and he believes that the rate would be even higher if it would account for dysfunctional
projects (i.e. projects with low quality, high cost, no users etc.) [4].
A probable reason for why the commercial software approach, currently, has a lower failure rate is, the
time it has had to develop its practice. For years it has been the methods of proprietary software that
have been reflected upon in universities and exercised by corporations. Consequently, many existing
methods have evolved, and new methods have emerged to be applicable to the approach of proprietary
software development. Experience has allowed the methodology to change for the better, and that is
what must be given to Open source development as well. The Open source approach is far from simple
and as it is fairly young, it is important to have patience in order to gain understanding to what would
lead to success. In the words of J.Zawinski (1999), one of the developers of the Mozilla project [20]:
” Open source does work, but it is most definitely not a panacea. If there’s a
cautionary tale here, it is that you can’t take a dying project, sprinkle it with
magic pixie dust of open source, and have everything magically work out.
Software is hard. The issues aren’t that simple”
2
There are many different views on what a software failure is. In this case it refers to dead projects.
8
3.1 Methods analysis
The development of Open source software differs from the traditional software development and
because of that, the development methods have to be different from each other. A relatively simple
way to identify one of the crucial differences in Open source software development is by looking at
when the requirements are gathered. As opposed to the traditional software development approach, the
requirements in Open source software projects are constantly increasing as they are gathered from
earlier releases of the project [21]. This makes it hard for the project to be functional using an older
development model (e.g. The Waterfall Model, Fig 1), which does not allow the developer to go back
to a previous phase.
Fig 1: Waterfall Model
Source: D. Pierce. (2011). Waterfall model. [22]
After much reading and research it becomes evident that, at present, the most preferred development
methods are the Agile software development methods (Fig 2), [23, 24]. While many of the earlier
traditional methods do not apply for Open source software development, the Agile methods have
many similarities and aspects that are very useful when developing Open source [25].
9
Fig 2: Iterative & Incremental Development
Source: Agile Methodology – Changing ways of software development. [26]
3.2 Methods recommendations
The nature of the Agile approach is that the methods are iterative and incremental. It revolves around
the ideas of delivering implementation of software quickly, enabling change rapidly, and allowing for
frequent modifications [27]. It also allows for changing the requirements late in the development
phases. These properties of the Agile methods fit well to ideas in Open source development. In
essence, the Agile methods are perfect for Open source development, since their ideas of development
have the same characteristics.
Successful Open source software are known for delivering fast updates and being able to adapt to user
requirements fast (e.g. Mozilla Firefox, Google Android, etc), and if we only look at the software
development process, Agile methodology is a great outline for Open source software development.
However, the Agile methods only involve the software development process, which is merely a part of
Open source. Not many Open source projects end up being successful, and a guaranteed way to fail
with such a project is to not appreciate the risks that it brings [4, 18, 19].
10
3.3 Failure analysis
When addressing aspects of software engineering, much of the focus is on identifying the clients’
needs. To be able to fulfill them (i.e. achieve a successful project) it is equally important to understand
the risks or factors of failure as the needs. For example, in traditional engineering there is the well
known Project triangle (Fig 3) that is an analytical tool for deciding what is most important for the
project in terms of budget, quality, and time. Eric Bethke (2003) states that only two out of three of
these goals can be achieved, and failure to understand that will result in the project missing more than
just one goal [28]. After identifying the needs and prime goals of the project, more work is put on
elaborating the project specification, which includes managing risks. Risk management is a method for
further identification of the risks. By grading the collected risks after importance, the method will
conclude in giving the project manager a greater understanding for preventing them. Both of these
two methods are greatly recommended for software engineers under traditional circumstances, but in
Open source, their usefulness may vary, since the risks and the goals are often different from those in
Closed traditional software development.
Fig 3: Project Triangle (P. Foroutan)
3.3.1 Costs
A big issue for software projects over the years has been their costs. It is an issue that often can lead to
the failure of a project and, as shown with the project triangle, should be planned for a soon as
possible in the early stages in the project cycle. There are many arguments that in Open source, cost
and monetary resources are not as critical as with Closed source. This might be closer to the truth for
entirely new Open source projects rather than for projects going from Closed source to Open source.
11
Contrary to the general belief, pre-existing Open source projects can be very expensive in short term
perspective [4, 29, 30]. One reason behind this is that the documentation and the code must be written
so that it can be understood by whoever wishes to become a part of the project. It is a feature that can
be very time consuming, and in most cases time is money. In addition, this must be done by previous
developers or by someone that is knowledgeable with the code and the project so that the translation is
correct [4].
Besides for costs that are exclusively linked to Open source development, there still remain
expenditures from previous development methods that in a similar manner affect Open source
projects. An example of such a cost is the quality assurance of software. In contrast to Closed source
development, this process can be applied to Open source projects differently, but is still equally
important, in particular for developers that aim to sell their software [30, 31].
3.3.2 Attraction
Another common downfall for Open source is the inability to attract developers to work on a specific
project. By making a project Open source, one opens the door for the source code to be publicly
inspected and modified. The problem with that is that many believe in the misconception that it is
solely enough, to make a project Open source, to attract people to work on the software [4, 32]. K.
Fogel (2009) said [4]:
” An open license does not guarantee that hordes of active developers will
suddenly volunteer their time to your project, nor does open-sourcing a
troubled project automatically cure its ills”
3.3.3 Motivation
In a different perspective, even if the project succeeds to attract volunteers, it is not certain that they
will be as productive as expected or even stay in the project long enough to make an impact. This
paradox is not unique for Open source or even Computer science; it is as general as the question: What
drives individuals to do what they do? The answer for that is:”motivation”.
To find what motivates the developers in Open source is not an entirely easy task. Often motivation is
connected to monetary bonuses or salary, and there are some companies that can make money from
offering services (e.g. Red Hat) or other products connected to Open source. The revenue made by
12
these companies can be part of the motivation for the developers, but many Open source volunteers
work without compensation during the development phase. For Open source, it is not as common with
monetary reward to induce motivation as it is with proprietary software [32, 33]. The motivation of
these developers tend to come from other sources, such as the project itself or the experience [33]. To
successfully address this situation it is important to identify how to motivate developers to stay in the
project, and more importantly how to attract them to it.
Cost, attraction, and motivation are all important aspects in Open source, however, not the only ones.
The Open source development method is, as stated earlier, fairly new and with that comes new
problems as well. Even though this work does not discuss all of the issues with Open source, it is
important to highlight the existence of them. A. Khanjani have identified some of them and
represented them in a table (Table 2), [34].
All of the faults listed by Khanjani are to be considered by anyone who attempts an Open source
project. Not all of them will necessarily lead to the immediate destruction of a project, but they can be
very costly and might lead to setbacks that may or may not be crucial. The most hazardous problems
in Open source are the ones concerning costs, attraction and motivation. Costs become an issue when
owners turn to Open source to save on monetary resources, and are not aware of the possible
investment that is needed, thus leading to abandonment of the project. Attraction and motivation are
even more important since they are the two “must have” in Open source, because there is no software
that can be created without developers. Thus, to increase the chances of having a successful Open
source project, a good foundation is needed, and that can only be done by overcoming these obstacles.
13
Table 2. Possible cons of Open source. Recreated: A. Khanjani, R. Sulaiman.
The Process of Quality Assurance under Open Source Software Development, pp 549.
Features
For Users
For Developers
For System
1. Useless
1. Lack of tools
1. Lack of formal
documentation
2. Collaboration
process; centralized
2. Unstructured
with new
management release
development
developers
and documentation
3. Irresponsible
3. Review of
2. Poor design
individuals
large projects
3. Hard estimation of
Pros & Cons
Cons
man power
4. No single
responsibility for
problem, lack of
liability
5. Version
proliferation
6. complex licenses
7. High short term
cost
14
3.4 Recommendations
3.4.1 Cost
Cost is a factor that will be a part of every project sooner or later, but not necessarily in the same form.
For example: In newer projects, cost can be considered the need of a specific non-free software, a
certain service, or even an indirect cost, such as the effort to promote the project rather than working
on it, and much more. In existing projects, as shown earlier, it can be the need for documentation,
making the code understandable for everyone, or setting up mailing-lists and more [4]. Whilst there is
no real way of eliminating costs, it is possible to minimize them.
Preparation is the keyword when dealing with costs. By preparing for the probable risk, it is likely to
find more optimal solutions than in a case where costs have been neglected. Many are unaware of the
possible expenditures that Open source requires until they reach a scenario that forces them to
recognize the problem. They will then, as most people in dire situations, search for a quick solution,
which is not always the most beneficial. To prevent the occurrence of an unforeseen event involving
cost, risk management is highly recommended (Table 3).
At first, it may seem time consuming to identify the factors of failure in an Open source project, since
they are not as well-known as they are in Closed source (i.e. not as obvious as in Closed source).
However, this will enable the risks and solutions to be considered without being pressured to act
quickly, and with more time, more solutions can be evaluated. Preparation will undoubtedly result in
better decision making and it is always better to be safe than sorry.
.
15
Table 3. Risk management plan for a project. Recreated: Software Engineering: Course Material
of Software Engineering, 4.4.4 A Practical Risk Management Planning Approach [35]
Risk
Prob.
Impact
Exp.
Mitigation
Plan
1
Failure to
High
High
High
Study white papers and
meet the high
guidelines on perf.
performance
(performance)
Train team on perf. tuning.
Update review checklist to
look for perf. pitfalls.
Test application for perf.
during system testing
2
Lack of
Med
Med
Med
Train resources.
people with
Review prototype with
right skills
customer.
Develop coding practices
3
Complexity of
Med
Med
Med
application
Ensure ongoing knowledge
transfer.
Deploy coding practices.
4
Manpower
Med
Med
Med
attrition
Train a core group of four
people.
Rotate assignments among
people.
Identify backup for key
roles.
5
Unclear
Med
Med
Med
requirements
Review a prototype.
Conduct a midstage review.
16
3.4.2 Attraction
Recruiting developers for a project is easier said than done, but it is imperative to have them.
Ultimately it is the developers that will lead the project to success or failure. To gather developers to
an Open source project it is important that the project is attractive. Only by attraction will people find
an interest for the project, and if it is high enough, the same people can begin to serve as developers.
Attraction can be accomplished through consideration of several parts of the project. Some of them, as
listed by K. Fogel (2009), are [4]:

Look around

Choose a good name

Clear mission statement
Prior to starting a project, the first step should be to look around for similar projects and more
importantly whether there are any similar active projects at that time point. It can be very costly if
there are projects successfully running with the same goals. First of all, an older project can have
developers that are already satisfied with the project they are developing, and do not wish to change.
Secondly, the project might be further into development, which is a serious disadvantage for a less
developed project (i.e. the other project will be more attractive). If a project with the same goals
already exists, it can be wise to collaborate with that project and try to reach an agreement with its
founders. Another possible scenario is that there are dead projects that, earlier, have had the same
objectives and have failed. In such case, it would be smart to study those projects as much as possible,
learn the reasons behind their failure and make sure a newer project does not make the same mistakes.
Lastly, if there are no similar projects, one can focus on other aspects of the project, such as choosing
an attractive name and mission statement.
The first thing that people will come in contact with is the name of the project. While the success or
failure of the project is not determined by its name, a good name really can help attracting people to it,
and a bad name can do the opposite. Furthermore, the project name should have some properties to it.
One, the name should be related to the project so that there are no misunderstandings and so that it is
easier to remember. Two, the name should be easy. A complicated name can be misleading and might
be irritating to people or even make them see the project as non-serious. Finally, the name should be
unique for that project. At this stage in project formation, one has to be careful to not steal an existing
name or create confusion by naming it after something with a too similar name.
While a good idea and a good name will take you a long way, there is more that can be done. A
mission statement is an example of what the interested developer will look for. If the developer likes
your project, the first thing he would do is to look for some extra information, and for that reason, it
would be great if the project has a well elaborated mission statement. The mission statement should
17
contain a quick description of the project and the goals, and it is at this phase that most developers
decide if they would like to know more about the project, and become a part of it, or not [4].
3.4.3 Motivation
When an Open source project has begun and the gathered volunteers have started their development
work, the next task is to keep them motivated. Similar to any other workplace, motivation is the factor
that drives people to perform in Open source while at the same time having a much stronger purpose.
As most people depend on their salaries, motivation will in many cases only affect their performance
at work. In open source, the developers begin their work without compensation directly linked to
performance and because of that, motivation does not only affect their performance, but also their will
to stay in the project.
In 2001, Alexander Hars mapped the reasons behind Open source developers’ motivation. He divided
them into two groups (Table 4): “Internal factors”, which are rooted in the psychology of the
individual, and “External rewards”, which have originated from the environment [33].
Table 4. Overview of motivational factors (P. Foroutan)
Internal factors
External rewards
Intrinsic motivation
Future rewards
Altruism
Personal needs
Community identification
Briefly described, Internal factors refer to what the Open source programmers choose to develop
because of their own leisure and liking, and not due to monetary incentive.
Intrinsic motivation, applied to Open source, is when the developers feel contentment, pleasure or
accomplishment when they are writing code.
Altruism is explained as when a person tries to help others at some cost to them self [36]. In Open
source, there are many developers that belong to this group, because they offer their service, without
gain, at the loss of their own energy, time, etc.
18
Community identification is the last group in Internal factors that are explained by Hars. The
programmers that belong to this group feel a strong connection to the Open source community and to
the people in it. They find motivation when taking part in Open source projects and helping their
fellow programmers in the same community (The Open source community).
The majority of Open source developers are not salaried with monetary rewards during their work.
Nonetheless, there are several external rewards in Open source that are appealing to the programmers,
and some of them can lead to indirect enhancements in revenue.
Future rewards is the main group in External rewards, and it contains the big number of
programmers that perceive their work as a future investment. The rewards of such investment may
differ and for that same reason, Hars divided this group into the following smaller parts:
Selling products and services is a lucrative part of Open source to those who wish to create an
income. In some cases, individuals or organizations provide services like support or consulting
for software that is already Open source, thus generating revenue from a program that is free3.
Human capital includes knowledge, capabilities and personality attributes in the work
environment. Created by economists, it is a collective term for the qualities a person gain
through education, training and experience (e.g. Open source projects) [37]. In brief,
programmers partake in Open source projects to acquire an improved skill set. This is seen as
a future reward as it eventually may lead to higher salaries or better job opportunities.
Self-marketing is a form of advertisement for the individual programmer. By participating in
Open source projects, they can efficiently put their capabilities and skills on display. This
advertisement is seen as a future reward, since it can, as in human capital, create better job
opportunities.
Peer recognition is actualized when a programmer receives praise or positive feedback from
his colleagues. It comes from the yearning for fame [38], and is seen as a future reward when
it has a positive effect on the developer’s effort.
Personal needs is not only a big part in motivation and external rewards, but also when it comes to
attraction [4]. It is described as, when there is a personal need for a certain service or software that
does not exist, leads to initiation of that project. Motivationally, the finished product of a needed
3
Free, as in there is no monetary cost to use the software.
19
software is the future reward; and if this need is of interest to other programmers, the project also can
produce a fair amount of attraction.
Conclusively, Hars gathered data from a survey on motivational drive that resulted in 79 valid
responses (Table 5). The results are interpreted to that the External factors have a bigger part than
anticipated. Although many are affected by both types of motivation, this survey confirms that
External factors are a larger source of motivation than Internal factors.
Table 5. Motivations of all programmer types. Source: A. Hars and O. Shaosong,
Working for free? Motivations of participating in open source projects, p. 7 [33]
Motivation
Percent
Internal factors
- Intrinsic motivation
79.7%
- Altruism
16.5%
- Community identity
27.8%
External factors
Future rewards
- Selling products and services
13.9%
- Human capital
88.3%
- Self-marketing
36.7%
- Peer recognition
43.0%
Personal need
38.5%
Attraction and motivation are two risks that are shaped in many different ways. The variety of their
appearance depends on the variety of the individuals that may become, or already are, a part of the
project. Anyone who wishes to start an Open source project, would do smart if they considered and
studied these factors in depth. In software engineering, a good start might play a vital role for the rest
of the project since problems can be difficult to solve and are very consuming in terms of resources
and time. Combining a good start with motivated developers during the ongoing project will not only
help, but can sometimes be sufficient to finish a project successfully. Nevertheless, there are several
other big changes in Open source that do not have an effect on the development of a project. One of
these enforces rules of distribution and defines the kind of software that is being made: licensing.
20
4. Licensing
Typically, when developing software using Closed source models, the final goal is to release that
software with the objective of generating sales and gaining advantages in the business market [39]. In
Open source, these objectives can be almost identical or completely opposed, depending on what the
creator or creators of the project wishes it to be. The main difference is “Licensing” (i.e. the use of
various licenses), which is a method that does not only separate Closed source from Open source, but
also set apart Open source projects from each other.
A license in Open source is a tool that is used to specify the rules regarding that particular project. It
regulates distribution rights and potential changes that others make to the source code [40]. Seen from
a bigger perspective, the licenses states what a user can or cannot do with the software [41]. There are
approximately 70 open source licenses that have been certified by the Open Source Initiative [42].
Grounded on the research of A. Engelfriet (2010), many of these licenses can be seen as copies of each
other with minor changes, and belong to one of three distinctive groups [40]:
Free-for-all licenses (a.k.a. Academic licenses). These licenses are the most permissive. The
only requirement is that credit is given to the original author of the code (i.e. derivate works
can be made proprietary as long as proper credit is given). The Berkeley license (BSD) and the
Massachusetts Institute of Technology license (MIT) are examples of free-for-all licenses.
Keep-open licenses. These licenses can be comprehended as the middle ground of Open
source licenses. Software under these licenses can be changed or altered as long as they are
made available as Open source. However, large works that include this kind of software can
be made proprietary; hence they are the middle ground. The GNU Lesser General Public
License (LGPL) and Mozilla Public License (MPL) are typical Keep-open licenses.
Share-alike licenses (a.k.a. Copyleft).The licenses in this group are more restrictive than most
others. Modified versions of this software, or software containing parts of it, must as a whole
be made available under the same license. Accordingly, software containing any source code
protected under these licenses cannot be made proprietary or be used in any proprietary
software. Furthermore, software containing Copyleft licenses must be distributed as Open
source. The GNU General Public License (GPL) and the Open Software License (OSL) are
characterized as Copyleft licenses.
21
The importance of Open source licenses has grown to have a crucial role as more corporations seek to
practice Open source. Consequently, the view of the licenses is not only technical, but also political
and legal [43]. For starters, not everyone has the authority to decide on which license to exercise.
Choosing a license requires that an individual or corporation has the full copyright of the source code
(i.e. the entire source code has been written by one or several employees of the corporation). A
developer only has the right to choose a license for the source code that he or she has written, hence
having full copyright is imperative. However, there are some exceptions where full copyright is not
necessary. Derivate works, using non-owned source code, can be released under different licenses if
the copyright holder of that code gives their permission to do so, or if the source code used is licensed
under a permissive or keep-open license that allows it. In addition to total freedom of license choice,
full copyright also makes it possible to explore more business model options, such as multi-licensing.
Multi-licensing is a business model that involves the distribution of one software under two or more
different licenses. By using the multi-licensing model, the distributor can either sell or give away
software under the license that the client wants, whether it is Open source or commercial. This said,
choosing the correct Open source license is not as trivial as it may seem. Many factors are to be
acknowledged before making any definite decisions regarding licenses, with the first being a deeper
understanding of the traits of the licenses.
4.1 License traits
GPL, LGPL and BSD are all common licenses in the Open source community. While these licenses
are very different from one another, they each represent one of the three earlier mentioned categories
that are separated by the level of restrictiveness or permissiveness that they hold (Fig 4). Nonetheless,
to fully appreciate the unique nature of OSI licenses, it is also important to understand their
similarities, which at minimum states that all source code must be available to licensees, and that no
income, in the form of licenses fees4, can be made from distributing the software [44].
4
One can sell Open source software, but cannot require a user to buy a license in order to be able to use it.
22
Fig 4. Categorization of OSS licenses. Source:
M. Kechagia et al. Open Source Licensing Across Package Dependencies, p. 29 [44]
Learning and understanding the full concept of these licenses is not always as basic as just reading
their contents. One of the reasons for that is because the rules and regulations described in the licenses
may be vague and can be misinterpreted. To make matters worse, the licenses are very strict and do
not allow for any deviation from these limitations, which are not always easily identified.
Furthermore, the Open source licenses have largely been written in regard to computers, therefore
creating issues when developing software for other hardware, such as cellular phones or in-home
routers. It is clear that the licenses were not written by lawyers, whom have practice with commercial
contract law, thus it might not only be the technical aspect that will give room for future confrontation,
but also the juridical [45]. In fact, there are a large number of court cases involving Open source
software due to either misinterpretation or disregard of license regulations.
To resolve this issue users tend to choose the more frequently used and existing licenses. This will
give room to observe previous cases of both success and failure where the license has been used in a
similar situation. In addition, the observation should as well give a clear estimate of the license
limitations. Nevertheless, deciding on what license to use requires more than just knowing the
licenses’ technical traits.
23
4.2 Choosing license
If the procedure of choosing a license begins with gaining knowledge about the different licenses, then
one must identify the user and the purpose of the license. In other words, it means that once one knows
what each tool (i.e. licenses) does, the next step is to decide whom (i.e. user) the tool is for and for
what task (i.e. purpose). Based on previous research by J. Lindman et al. (2010, 2011), the latter part
of the license decision model is affected by several factors (Fig 5), [41, 43].
Fig 5. License decision factors. Source: J. Lindman, M et al.
Matching Open Source Software Licenses with Corresponding Business Models, p. 34
Demonstrated in figure 5, the distinction between the two sides of “License decision” is that the
elements in the left column are directly, or indirectly, connected to factors outside the corporation,
while the right column represents internal factors within the corporation. The external elements consist
of: Externalities, Motivation creation, Leadership, and Company size.
Externalities are factors that will force a specific license or license type upon a project. Typically,
existing Open source projects already have decided on a license, and new contributors have to abide
by that choice. Another case would be if a company wishes or needs to use other established code
(bundling) in their project that uses a restrictive license, such as GPL. This will limit the original
project to use the same license, or alternatively to not use that code at all.
Motivation creation is overall when project creators use a license to motivate and attract developers
to their project. As previously mentioned, motivation can be extremely important for Open source
projects, foremost for new projects that are not funded by bigger corporations. A restrictive license
motivates developers in the sense that it assures that the project will remain Open source, thus
guaranteeing that their work will not be concealed or made proprietary.
24
Leadership is connected to the amount of control in a project. In many cases, strong leadership can
prevent upcoming risks and quickly solve problems. Linked to licensing, a good leadership may be
vital for an Open source project, especially when using a permissive license. If such projects are
subject to bad leadership, problems like Software code forking can arise; which is when a developer
from the team writing the software independently develops his or her own version of the software,
thereby creating two disparate versions. Good leaders should be prepared for that such troubles can
occur or in the best case prevent them by having all interested parties collaborating.
Company size literally refers to the size of the company. Smaller companies need to analyze their
choice of license, both legally and technically, and tend to use the more popular existing licenses.
However, larger companies have more room to experiment and can create new paths in Open source
licensing. This might not be successful in the long run, but the difference is that the large companies
can often afford to take risks and make mistakes.
All of these factors, whether together or individually, can affect the choice of license for a particular
project. In addition, no matter what the reason is for choosing a specific license, the most important
factor is that the choice corresponds with the intended business model. Different licenses restrict a
corporation’s possibility on creating revenue in various ways. For example: if a company plans on
selling support for Open source software, like the Red Hat business model, then licenses like GPL or
LGPL are suitable licenses. Their restrictiveness assures that the software remains Open source and is
free, but does not prohibit a corporation to sell support and services connected to the program in a
proprietary manner, which can be a great source of income. In another case, if a corporation has a
different business model, such as selling the software in a bundle, the appropriate licenses would be
one of the more permissive ones.
4.3 Recommendations
The OSI certified licenses are subject to change from time to time. Either some existing licenses are
updated and released as new licenses (often with the same name followed by higher version number)
or there can be licenses that are created from square one and are new. In any case, users that are new to
Open source licensing are recommended to seek as much knowledge as possible about the licenses,
both theoretically and practically, prior to choosing a license. This can be done by visiting the OSI
homepage5, for the most up to date information about the licenses, and by finding projects that have
practiced with the specific license or licenses before. After enough knowledge has been gathered, a
corporation must decide on what type of license they need for the selected business model. Different
5
http://www.opensource.org/licenses/alphabetical
25
licenses limit and permit different business paths of the software, thus making it very important that a
compatible license has been chosen. Therefore, when choosing a license, the focus should primarily be
on the business model, although other factors also can be taken into consideration [43].
While the business model directs the creator of the project to the correct group of licenses (e.g.
permissive, weak-restrictive, and restrictive), factors such as Externalities, Motivation creation,
Leadership, and Company size can help on deciding which specific license to choose. Many
corporations and projects share similar business models, but their resources and surroundings create
unique situations. The factors, unlike the business model, take these attributes into account, thus being
able to identify the better choice when comparing similar licenses. Though, it is important that the
license choice is within the boundaries set by the business model, even if by solely looking at the
factors suggest taking a different approach (i.e. choose a different type of license).
Licensing, as in the case of developing, requires a proper amount of time. However, since time is the
most valuable resource in software development, the urge to complete a project quickly can become
greater than to do it thoroughly. To some extent it is true that completing a project in a shorter amount
of time can save some costs, but a bad choice of license will be more expensive. Therefore, every
project manager should take their time on deciding the correct license to use, thus not exposing a
project of unnecessary risk, which is a far greater reward than it is as a cost.
Keep in mind that there is more than one way to exploit a specific license. In some cases a license
might be used for its possibility to create income, whilst in others for its knowledge management. For
more in depth understanding of license compatibility in various types of projects, two examples are
given in the following scenarios.
26
5. Scenarios
The purpose of this study is to give the reader a deeper insight into the interplay between the license
and business model, by showing how the same license can be utilized in different ways with various
types of software. The study is conducted by reviewing the possibilities and limitations set by GNU
Public License (GPL) in two different categories of software; on one side there are standalone types of
software, like a web browser or operating system, where the source code for the software itself is the
wanted product and on the other side, there are software like code generators and compilers where the
sought product is the source code created by the software.
In scenario one, the study is focusing on the standalone software Linux in a successful case where the
choice of Open source license GPL which is one of the most restrictive licenses, in combination with a
compatible business model, has enabled corporations (e.g. Red Hat) to create a thriving revenue
stream.
In scenario two, the study shifts towards the second category of software and analyzes the code
generator gSOAP and GPL, that is a case where the GPL solely is not enough for creating revenue, but
does allow for other benefits of the license, such as restricting code forking and gaining developers.
5.1 Scenario 1: Linux and GPL
In the year of 1991, the operating system (OS) Linux was introduced to the world by Linus Torvalds.
The project, which is one of the most renowned Open source software, has frequently been observed
because of its success, both during its developmental phase and now in business. In fact, even though
he is the principal author and often associated with the operating system, L.Torvalds (1997)
acknowledged that [46]:
”I would like to make it very clear that the Linux operating system is a huge
project done co-operatively by lots of people all over the world. […] just the
kernel contains code from hundreds of people from around the world.”
The Linux operating system is licensed under the GPL-2.0 (version 2.0), thus making it much more
commercially restrictive than its competitors (e.g. Windows OS and Mac OS). Even so, since its
creation it did not take long before several corporations identified and applied compatible business
models to the new operating system; with one of them being the “Red Hat”.
27
Founded in 1993, the Red Hat corporation is one of the biggest and first distributors of the Linux OS
[47]. The corporation quickly became successful and much of it was, amongst others, due to their
early implementation of a well-matched business model for Linux and GPL, which is partially
exercised even at the present. The formula that crafted the successful business model was simply Red
Hat’s ability to identify the needs of the Linux OS users [48]. Unlike many others, Red Hat did not
just focus their attention on the software itself, but also on the services that the user required,
especially corporations. In addition, the GPL-2.0restricted the corporation from selling the software in
the same manner as their proprietary competitors, and so became the professional Open source
company Red Hat.
Throughout time the Red Hat business model has been subject to minor changes and is at this time
point perfectly adapted to the needs of their clients. The corporation has currently over 4000
employees and was ranked 19th place in America's 25 fastest-growing tech companies by Forbes6,
2011 [49]. By understanding both the market and the software (i.e. license), the successful progression
of the Red Hat business shows that it is possible for a professional Open source corporation to rise to
the level of those who solely or mainly work with commercial licenses.
5.1.1 The Red Hat license depending business model
The concept of the Red Hat business model is to sell subscriptions for services that are connected to
the various software products. Included in the subscription is also that Red Hat will provide a
packaged version of the Open source software with corresponding updates as soon as they are made.
This model can be perceived as giving the clients a complete package as the subscription contains both
services and software [50]. However, a big component for the Red Hat success is not solely that they
provide the services, but also that the services are well developed and high in quality.
Some of the services that Red Hat offer are support, training and professional maintenance for the
software [51]. For corporations, these services have become very lucrative, since technical problems
and low employee effectiveness can be very expensive. Furthermore, Red Hat offers a variety of
subscriptions that include different levels of service, thus granting their clients the freedom to only pay
for what they need.
In summary, the value of a Red Hat subscription is in the whole package with the services, and not
exclusively just the software. This business model is exceptionally well-suited with the GPL-2.0 or
any other restrictive license as the license brings down the value of the software from a sales
6
An American publishing and media company
28
perspective. The combination of the Red Hat Open source software and their services, is a product that
has enabled them to keep and expand their clientele, and doing so without breaking the GPL-2.0
regulations. Though, it should be noted that this business model only works for the standalone type of
software (i.e. Linux). Code generators and compilers have other difficulties when licensed under the
GPL; especially, in cases when corporations, that develop proprietary licensed software, are looking to
use source code protected by the GPL.
5.2 Scenario 2: gSOAP and GPL
The software gSOAP is an Open source C and C++ software development toolkit created by Dr.
Robert A. van Engelen at Florida State University, USA [52]. It is a software that analyzes WSDLs
(Web Services Description Language) and XML schemas, and maps the XML schema types and the
SOAP messaging protocols to efficient C and C++ code; or it can simply be used for converting XML
to or from C and C++ data [53]. Concisely, gSOAP is a compiler-based code generator.
GSOAP, as Linux, is also an example of Open source software licensed under GPL-2.0 that has been
proven to be successful. The toolkit is used by many corporations worldwide, including several top
technology companies, such as IBM, Microsoft, HP and many more [53]. However, since gSOAP
belong to the second category of software, it would not have reached this success if it had applied the
business model used by Red Hat.
The problem that the GPL-2.0 causes the business aspect of software like gSOAP is due to its Copyleft
nature that necessitate that all derived work of such software, even if it is a small part, must be
licensed under the GPL-2.0. Unlike purely transformational compilers such as GNU Compiler
Collection (GCC), the gSOAP output includes algorithms for run-time processing (i.e. efficiency) that
are not part of the input but are rather emitted to optimize the code generate by gSOAP. Therefore,
compilers that solely transform code can preserve the original license of the input whereas the gSOAP
output must be licensed under the GPL-2.0. For many corporations active in the commercial software
market, restrictive licensed output is not appealing as they may want to integrate the generated code
into software under a proprietary license. Knowing this predicament, Dr. van Engelen utilized a
different approach than Red Hat, namely the Multi-licensing business model.
5.2.1 The gSOAP Multi-licensing business model
Being the sole developer and full copyright holder of the gSOAP code, Dr van Engelen had the option
of using the multi-licensing business model. This has resulted in two different main types of gSOAP
29
software, one is the Open source gSOAP that is licensed under GPL-2.0, and the other is a gSOAP
version under a commercial software license.
From the business perspective the commercial version of gSOAP is by itself enough to achieve
success. In comparison to Red Hat and Linux, the project does not have to be Open source at this time
point and probably not in the future either. Especially so since Dr. van Engelen does not accept any
third-party GPL contributions to avoid having to fork the code in both versions, thus he is and will
remain the sole copyright holder [53]. When asked why he chooses to have an Open source version of
the software, he responded:
” I wanted to start an Open source project and give back something to the
community”
If anyone decides to further develop or redistribute the software, it can only be done under the GPL2.0. Therefore, gSOAP software is always protected and Dr. van Engelen can openly share the source
code without hampering commercial development opportunities of his company and be able to
continue to meet contractual obligations with clients.
The multi-licensing business model is a great approach for those who want to explore the possibilities
of a different license choice. In fact, a copyright holder can experiment with as many licenses he or
she chooses, given that there is no limitation in multi-licensing. Nonetheless, much caution is advised
when changing a license. For example, if the software in this case had been Linux, the GPL-2.0 would
not have been sufficient enough to keep competitors from making profit on the software.
Consequently, it is important that the copyright holder knows the rules and regulations of a license and
how it will affect the project. A wrong choice of license can turn out to be destructive for the business
model and ultimately be much more costly than helpful.
5.3 Scenarios conclusion
What this study has shown, is that the one and same Open source license can have very different
impact and relevance on various projects. Depending on the type of software and situation, a license
can be anything from a hindrance to an aid. For example: In the scenario of Linux, the GPL-2.0 is
perceived as a hindrance as the Red Hat corporation does not have the rights to change the license and
has to abide by its regulations. Although confronted by this obstacle, Red Hat overcame the problem
by implementing their innovative business model and has become successful in creating big revenue.
While in the second scenario with gSOAP, the GPL-2.0 is considered an aid as the copyright holder,
30
Dr. van Engelen, is not required to release the software as Open source, but chooses do so. He believes
it is important to help the Open source community, and by combining the multi-licensing model and
the GPL-2.0, he has been able to do so without compromising his own interest.
Ultimately, if the interplay between license and business model is good, the project will have much
higher prospect of success. For some cases, a compatible license must be chosen for the select
business model, and for others, it is vice versa. Nevertheless, the identification of the best suited
combination for a certain project is a task for its creator.
31
6. Conclusion
Developing Open source projects is not an easy task. Like any type of software production, Open
source development comes along with risks (e.g. costs, attraction and motivation) that must be
properly planned and accounted for. Not surprisingly, the fast changes and increasing requirements in
Open source projects call for methods of development that are able to cope with them, such as the
Agile methods. While management of these aspects are guaranteed to help a project in its development
and initiation, it is equally important that the product is given a fair opportunity for success, which
necessitates a suitable Open source license for the project’s business model.
Open source licenses is a factor that must be taken very seriously and it is crucial that their importance
is understood. Primarily, it is not that the correct license will absolutely ensure success, but rather that
the wrong choice of license have a high chance of ruining a project’s present and future plans for
profit. Additionally, users of Open source software, especially corporations, should also revise the
license in order to not encounter legal and technical problems.
During a long time it was the general belief that Open source licensed software does not offer equal
revenue possibilities to software under a proprietary license. However, in recent years this argument
has been heavily disproved by numerous successful Open source projects, such as the Red Hat Linux
and Google’s Android. These projects are evidence that if Open source projects are successfully
developed and managed, high rewards can be claimed. Open source methodology has given
developers the opportunity to release high quality software under different circumstances than in
traditional software development and may very well boost a corporation’s reputation. With this said, if
developed properly, Open source software can be a great asset with endless possibilities.
32
References
[1]
J. Lanier, You are not a gadget: A manifesto, 1 ed. United States: Alfred A. Knopf,
2010.
[2]
A. Khanjani and R. Sulaiman, "The aspects of choosing open source versus closed
source," in Computers & Informatics (ISCI), 2011 IEEE Symposium on, 2011, pp.
646-649.
[3]
C. H. Museum. DECUS. Available: http://pdp-1.computerhistory.org/pdp1/index.php?f=theme&s=4&ss=7 (Retrieved: December 15, 2011)
[4]
K. Fogel. (2009). How to run a successfull free software project - Producing Open
source software.
[5]
B. M. Leiner, V. G. Cerf, D. D. Clark, R. E. Kahn, L. Kleinrock, D. C. Lynch, J.
Postel, L. G. Roberts, and S. Wolff. A brief history of the Internet. Available:
http://www.isoc.org/internet/history/brief.shtml (Retrieved: September 6, 2011)
[6]
IBM. History of IBM - 1960s. Available: http://www03.ibm.com/ibm/history/history/decade_1960.html (Retrieved: September 6, 2011)
[7]
D. Marshall. History of the Internet: Timeline. Available:
http://www.netvalley.com/archives/mirrors/davemarsh-timeline-1.htm (Retrieved:
September 6, 2011)
[8]
J. Gonzalez Barahona, "A brief history of free software and open source," IEEE
software, vol. 16, p. 32, 1999.
[9]
R. Stallman. (2011). The GNU Project. Available:
http://www.gnu.org/gnu/thegnuproject.html (Retrieved: September 6, 2011)
[10]
E. Capra, C. Francalanci, and F. Merlo, "An Empirical Study on the Relationship
Between Software Design Quality, Development Effort and Governance in Open
Source Projects," Software Engineering, IEEE Transactions on, vol. 34, pp. 765-782,
2008.
[11]
Open Source Initiative. History of the OSI. Available:
http://www.opensource.org/history (Retrieved: September 8, 2011)
[12]
OSS Watch. What is Open source software? Available: http://www.osswatch.ac.uk/resources/opensourcesoftware.xml (Retrieved: September 15, 2011)
[13]
Red Hat. Why Open source? Available: http://www.redhat.com/about/whyopensource/
(Retrieved: September 15, 2011)
[14]
Open Source Initiative. The Open Source Definition. Available:
http://www.opensource.org/docs/osd (Retrieved: September 8, 2011)
33
[15]
S. Raghunathan, A. Prasad, B. K. Mishra, and C. Hsihui, "Open source versus closed
source: software quality in monopoly and competitive markets," Systems, Man and
Cybernetics, Part A: Systems and Humans, IEEE Transactions on, vol. 35, pp. 903918, 2005.
[16]
GBdirect. Benefits of using Open source software. Available: http://opensource.gbdirect.co.uk/migration/benefit.html (Retrieved: September 8, 2011)
[17]
G. DeKoenigsberg, "How Successful Open Source Projects Work, and How and Why
to Introduce Students to the Open Source World," in Software Engineering Education
and Training, 2008. CSEET '08. IEEE 21st Conference on, 2008, pp. 274-276.
[18]
W. Scacchi, J. Feller, B. Fitzgerald, S. Hissam, and K. Lakhani, "Understanding
Free/Open Source Software Development Processes," Software Process: Improvement
and Practice, vol. 11, pp. 95-105, 2006.
[19]
G. Madey, V. Freeh, and R. Tynan, "Modeling the F/OSS community: a quantitative
investigation," in Free/Open Source Software Development, ed. Free/Open Source
Software Development, S. Koch: S. Koch, Ed.: Idea Group Publishing, 2004, pp. 203221.
[20]
J. Zawinski. (1999). Resignation and postmortem. Available:
http://www.jwz.org/gruntle/nomo.html (Retrieved: September 22)
[21]
J. E. Robbins, "Adopting Open Source Software Engineering (OSSE) Practices by
Adopting OSSE Tools," Making Sense of the Bazaar: Perspectives on Open Source
and Free Software, 2003.
[22]
D. Pierce. (2011). Waterfall model. Available: http://duncanpierce.org/node/177
(Retrieved: September 26, 2011)
[23]
P. Tsirakidis, F. Kobler, and H. Krcmar, "Identification of Success and Failure Factors
of Two Agile Software Development Teams in an Open Source Organization," in
Global Software Engineering, 2009. ICGSE 2009. Fourth IEEE International
Conference on, 2009, pp. 295-296.
[24]
F. Alfonso, "Open source software––an evaluation," Journal of Systems and Software,
vol. 66, pp. 77-90, 2003.
[25]
G. Lee and W. Xia, "TOWARD AGILE: AN INTEGRATED ANALYSIS OF
QUANTITATIVE AND QUALITATIVE FIELD DATA ON SOFTWARE
DEVELOPMENT AGILITY," MIS Quarterly, vol. 34, pp. 87-114, 2010.
[26]
(2011). Agile Methodology – Changing ways of software development. Available:
http://www.otssolutions.com/blog/?p=62 (Retrieved: September 28, 2011)
[27]
W. Cunningham and et al. (2001). Principles behind the Agile Manifesto. Available:
http://agilemanifesto.org/principles.html (Retrieved: September 28, 2011)
[28]
E. Bethke, Game development and production. Plano, Tex.: Wordware Pub., 2003.
34
[29]
T. Waring and P. Maddocks, "Open Source Software implementation in the UK public
sector: Evidence from the field and implications for the future," International Journal
of Information Management, vol. 25, pp. 411-428, 2005.
[30]
P. Maki-Asiala and M. Matinlassi, "Quality Assurance of Open Source Components:
Integrator Point of View," in Computer Software and Applications Conference, 2006.
COMPSAC '06. 30th Annual International, 2006, pp. 189-194.
[31]
L. M. Karg, M. Grottke, and A. Beckhaus, "Conformance quality and failure costs in
the software Industry: An empirical analysis of open source software," in Industrial
Engineering and Engineering Management, 2009. IEEM 2009. IEEE International
Conference on, 2009, pp. 1386-1390.
[32]
M. Grottke, L. M. Karg, and A. Beckhaus, "Team Factors and Failure Processing
Efficiency: An Exploratory Study of Closed and Open Source Software
Development," in Computer Software and Applications Conference (COMPSAC),
2010 IEEE 34th Annual, 2010, pp. 188-197.
[33]
A. Hars and O. Shaosong, "Working for free? Motivations of participating in open
source projects," in System Sciences, 2001. Proceedings of the 34th Annual Hawaii
International Conference on, 2001, p. 9 pp.
[34]
A. Khanjani and R. Sulaiman, "The process of quality assurance under open source
software development," in Computers & Informatics (ISCI), 2011 IEEE Symposium
on, 2011, pp. 548-552.
[35]
(2011). Software Engineering: Course Material of Software Engineering. Available:
http://rpl-blog.blogspot.com/2010/03/444-practical-risk-management-planning.html
(Retreived: October 10, 2011)
[36]
J. R. Ozinga, Altruism: Praeger, 1999.
[37]
A. O'Sullivan and S. M. Sheffrin, Economics: Principles in Action: Pearson Prentice
Hall, 2002.
[38]
C. DiBona and S. Ockman, Open Sources: O'Reilly Media, Inc, 1999.
[39]
W. Ming-Wei and L. Ying-Dar, "Open source software development: an overview,"
Computer, vol. 34, pp. 33-38, 2001.
[40]
A. Engelfriet, "Choosing an Open Source License," Software, IEEE, vol. 27, pp. 4849, 2010.
[41]
J. Lindman, A. Paajanen, and M. Rossi, "Choosing an Open Source Software License
in Commercial Context: A Managerial Perspective," in Software Engineering and
Advanced Applications (SEAA), 2010 36th EUROMICRO Conference on, 2010, pp.
237-244.
[42]
Open Source Initiative. Licenses by Name. Available:
http://www.opensource.org/licenses/alphabetical (Retrieved: November 1, 2011)
35
[43]
J. Lindman, M. Rossi, and A. Puustell, "Matching Open Source Software Licenses
with Corresponding Business Models," Software, IEEE, vol. 28, pp. 31-35, 2011.
[44]
M. Kechagia, D. Spinellis, and S. Androutsellis-Theotokis, "Open Source Licensing
Across Package Dependencies," in Informatics (PCI), 2010 14th Panhellenic
Conference on, 2010, pp. 27-32.
[45]
M. Välimäki, The rise of open source licensing a challenge to the use of intellectual
property in the software industry. Helsinki, Finland: Turre Publishing, 2005.
[46]
L. Torvalds, "Linux: a Portable Operating System," Masters of Science, Department of
Computer Science, University of Helsinki, Report C-1997-12, 1997.
[47]
R. Hat. Red Hat History. Available:
http://www.redhat.com/about/companyprofile/history/ (Retrieved: November 30,
2011)
[48]
T. Chung. History of Red Hat Linux. Available:
http://fedoraproject.org/wiki/History_of_Red_Hat_Linux (Retrieved: December 01,
2011)
[49]
Red Hat. Corporate fact sheet for Red Hat. Available:
http://www.redhat.com/about/companyprofile/facts/ (Retrieved: November 30, 2011)
[50]
Red Hat. Server Operating Systems. Available:
http://www.redhat.com/apps/store/server/ (Retrieved: December 2, 2011)
[51]
Red Hat. Value of a Red Hat subscription. Available:
http://www.redhat.com/about/mission/business_model.html (Retrieved: November 30,
2011)
[52]
R. A. van Engelen. Robert A. van Engelen. Available:
http://www.cs.fsu.edu/~engelen/index.html (Retrieved: December 5, 2011)
[53]
R. A. van Engelen. The gSOAP Toolkit for SOAP Web Services and XML-Based
Applications. Available: www.cs.fsu.edu/~engelen/soap.html (Retrieved: December 5,
2011)
36
TRITA-CSC-E 2012:012
ISRN-KTH/CSC/E--12/012-SE
ISSN-1653-5715
www.kth.se