What is the model of
development of Open source software? Explain the Open Source licensing policy.
Ans
model of development of Open source software
In the traditional model of development, which he called
the cathedral model, development takes place in a centralized way. Roles are
clearly defined. Roles include people dedicated to designing (the architects),
people responsible for managing the project, and people responsible for
implementation. Traditional software engineering follows the cathedral model.
Fred P. Brooks in his book The Mythical Man-Month advocates this model. He goes
further to say that in order to preserve the architectural integrity of a
system, the system design should be done by as few architects as
possible.[citation needed]
The bazaar model, however, is different. In this model,
roles are not clearly defined. Gregorio Robles[18] suggests that software
developed using the bazaar model should exhibit the following patterns:
Users should be treated as co-developers
The users are treated like co-developers and so they
should have access to the source code of the software. Furthermore users are
encouraged to submit additions to the software, code fixes for the software,
bug reports, documentation etc. Having more co-developers increases the rate at
which the software evolves. Linus's law states, "Given enough eyeballs all
bugs are shallow." This means that if many users view the source code,
they will eventually find all bugs and suggest how to fix them. Note that some
users have advanced programming skills, and furthermore, each user's machine
provides an additional testing environment. This new testing environment offers
that ability to find and fix a new bug.
Early releases
The first version of the software should be released as
early as possible so as to increase one's chances of finding co-developers
early.
Frequent integration
Code changes should be integrated (merged into a shared
code base) as often as possible so as to avoid the overhead of fixing a large
number of bugs at the end of the project life cycle. Some open source projects
have nightly builds where integration is done automatically on a daily basis.
Several versions
There should be at least two versions of the software.
There should be a buggier version with more features and a more stable version
with fewer features. The buggy version (also called the development version) is
for users who want the immediate use of the latest features, and are willing to
accept the risk of using code that is not yet thoroughly tested. The users can
then act as co-developers, reporting bugs and providing bug fixes.
High modularization
The general structure of the software should be modular
allowing for parallel development on independent components.
Dynamic decision making structure
There is a need for a decision making structure, whether
formal or informal, that makes strategic decisions depending on changing user
requirements and other factors. Cf. Extreme programming.
Open Source licensing policy.
A license defines the rights and obligations that a
licensor grants to a licensee. Open source licenses grant licensees the right
to copy, modify and redistribute source code (or content). These licenses may
also impose obligations (e.g., modifications to the code that are distributed
must be made available in source code form, an author attribution must be
placed in a program/ documentation using that open source).
Authors initially derive a right to grant a license to
their work based on the legal theory that upon creation of a work the author
owns the copyright in that work. What the author/licensor is granting when they
grant a license to copy, modify and redistribute their work is the right to use
the author’s copyrights. The author still retains ownership of those
copyrights, the licensee simply is allowed to use those rights, as granted in
the license, so long as they maintain the obligations of the license. The
author does have the option to sell/assign, versus license, their exclusive
right to the copyrights to their work; whereupon the new owner/assignee
controls the copyrights. The ownership of the copyright (the
"rights") is separate and distinct from the ownership of the work
(the "thing") – a person can own a copy of a piece of code (or a copy
of a book) without the rights to copy, modify or redistribute copies of it
When an author contributes code to an open source
project (e.g., Apache.org) they do so under an explicit license (e.g., the
Apache Contributor License Agreement) or an implicit license (e.g., the open
source license under which the project is already licensing code). Some open
source projects do not take contributed code under a license, but actually
require (joint) assignment of the author’s copyright in order to accept code
contributions into the project (e.g., OpenOffice.org and its Joint Copyright
Assignment agreementPlacing code (or content) in the public domain is a way of
waiving an author’s (or owner’s) copyrights in that work. No license is
granted, and none is needed, to copy, modify or redistribute a work in the
public domain
No comments:
Post a Comment