Tuesday, 9 August 2011

Development Philosophy

In his 1997 essay The Cathedral and the Bazaar, open source evangelist Eric S. Raymond suggests a model for developing OSS known as the bazaar model. Raymond likens the development of software by traditional methodologies to building a cathedral, "carefully crafted by individual wizards or small bands of mages working in splendid isolation". He suggests that all software should be developed using the bazaar style, which he described as "a great babbling bazaar of differing agendas and approaches."

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.

The bazaar model, however, is different. In this model, roles are not clearly defined. Gregorio Robles suggests that software developed using the bazaar model should exhibit the following patterns:-

1. 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 that, "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.

2. 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.

3. 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.

4. 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.

5. High modularization
The general structure of the software should be modular allowing for parallel development on independent components.

6. 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.

Data suggests, however, that OSS is not quite as democratic as the bazaar model suggests. An analysis of five billion bytes of free/open source code by 31,999 developers shows that 74% of the code was written by the most active 10% of authors. The average number of authors involved in a project was 5.1, with the median at 2.

Widely Used Open Source Products

Open source software (OSS) projects are built and maintained by a network of volunteer programmers. Prime examples of open source products are the Apache HTTP Server, the e-commerce platform osCommerce and the internet browser Mozilla Firefox. One of the most successful open source products is the GNU/Linux operating system, an open source Unix-like operating system. In some fields, open software is the norm, like in VoIP applications with Asterisk (PBX). Open source standards are not, however, limited to open-source software. For example, Microsoft has also joined the open-source discussion with the adoption of their OpenDocument format as well as creating another open standard, the Office Open XML formats.

Business Models

There are a number of commonly recognized barriers to the adoption of open source software by enterprises. These barriers include the perception that open source licenses are viral, lack of formal support and training, the velocity of change, and a lack of a long term roadmap. The majority of these barriers are risk-related.

From the other side, not all proprietary projects disclose exact future plans, not all open source licenses are equally viral and many serious OSS projects (especially operating systems) actually make money from paid support and documentation.
A commonly employed business strategy of commercial open-source software firms is the dual-license Strategy, as demonstrated by Ingres, MySQL, Alfresco, and others.

Non-Software Use

The principles of open source have been adapted for many forms of user generated content and technology, including open source hardware. Supporters of the open content movement advocate some restrictions of use, requirements to share changes, and attribution to other authors of the work.

This “culture” or ideology takes the view that the principles apply more generally to facilitate concurrent input of different agendas, approaches and priorities, in contrast with more centralized models of development such as those typically used in commercial companies.

Proliferation of The Term

While the term "open source" applied originally only to the source code of software, it is now being applied to many other areas such as open source ecology, a movement to decentralize technologies so that any human can use them. However, it is often misapplied to other areas which have different and competing principles, which overlap only partially.

Peren's Principles

Under Perens' definition, open source describes a broad general type of software license that makes source code available to the general public with relaxed or non-existent copyright restrictions. The principles, as stated, say absolutely nothing about trademark or patent use and require absolutely no cooperation to ensure that any common audit or release regime applies to any derived works. It is an explicit "feature" of open source that it may put no restrictions on the use or distribution by any organization or user. It forbids this, in principle, to guarantee continued access to derived works even by the major original contributors.

Sunday, 7 August 2011

History & The Term Free in Open Source Software...

The free software movement was launched in 1983. In 1998, a group of individuals advocated that the term free software should be replaced by open source software (OSS) as an expression which is less ambiguous and more comfortable for the corporate world. Software developers may want to publish their software with an open source license, so that anybody may also develop the same software or understand its internal functioning.

Open source software generally allows anyone to create modifications of the software, port it to new operating systems and processor architectures, share it with others or, in some cases, market it. Scholars Casson and Ryan have pointed out several policy-based reasons for adoption of open source, in particular, the heightened value proposition from open source (when compared to most proprietary formats) in the following categories:-

1. Security
2. Affordability
3. Transparency
4. Perpetuity
5. Interoperability
6. Localisation

Particularly in the context of local governments (who make software decisions), Casson and Ryan argue that "governments have an inherent responsibility and fiduciary duty to taxpayers" which includes the careful analysis of these factors when deciding to purchase proprietary software or implement an open-source option.

The Open Source Definition, notably, presents an open source philosophy, and further defines the terms of usage, modification and redistribution of open source software. Software licenses grant rights to users which would otherwise be reserved by copyright law to the copyright holder. Several open source software licenses have qualified within the boundaries of the Open Source Definition. The most prominent and popular example is the GNU General Public License (GPL), which “allows free distribution under the condition that further developments and applications are put under the same licence” thus also free. While open source distribution presents a way to make the source code of a product publicly accessible, the open source licenses allow the authors to fine tune such access.

The open source label came out of a strategy session held on April 7, 1998 in Palo Alto in reaction to Netscape's January 1998 announcement of a source code release for Navigator (as Mozilla). A group of individuals at the session included Tim O'Reilly, Linus Torvalds, Tom Paquin, Jamie Zawinski, Larry Wall, Brian Behlendorf, Sameer Parekh, Eric Allman, Greg Olson, Paul Vixie, John Ousterhout, Guido van Rossum, Philip Zimmermann, John Gilmore and Eric S. Raymond. They used the opportunity before the release of Navigator's source code to clarify a potential confusion caused by the ambiguity of the word "free" in English.

Many people claimed that the birth of the Internet, since 1969, started the open source movement, while others do not distinguish between open source and free software movements. The Free Software Foundation (FSF), started in 1985, intended the word "free" to mean freedom to distribute and not freedom from cost. Since a great deal of free software already was (and still is) free of charge, such free software became associated with zero cost, which seemed anti-commercial.

The Open Source Initiative (OSI) was formed in February 1998 by Eric S. Raymond and Bruce Perens. With at least 20 years of evidence from case histories of closed software development versus open development already provided by the Internet developer community, the OSI presented the 'open source' case to commercial businesses, like Netscape. The OSI hoped that the usage of the label "open source", a term suggested by Peterson of the Foresight Institute at the strategy session, would eliminate ambiguity, particularly for individuals who perceive "free software" as anti-commercial.

They sought to bring a higher profile to the practical benefits of freely available source code, and they wanted to bring major software businesses and other high-tech industries into open source. Perens attempted to register "open source" as a service mark for the OSI, but that attempt was impractical by trademark standards. Meanwhile, due to the presentation of Raymond's paper to the upper management at Netscape—Raymond only discovered when he read the Press Release, and was called by Netscape CEO Jim Barksdale's PA later in the day Netscape released its Navigator source code as open source, with favorable results.