Robert McCulloch – System Engineer

 Open Source Applications

Web Applications

If you set aside navagation, most business web sites function the same. Some companies develop specialized web applications to address the needs of their praticular industries visitors. In the past, web applications were costly to develop and implement and only companies with substancial finincal resources could aford to use them.

 But times have changed and so has the Internet and everything to do with web sites. The avability and varity of Web Applications has exploded and the cost to implement them has fallen as well. The advent of OpenSource has changed the Web Applications market making the most advanced state of the art web applications all but free to use. The only cost remaining is the setup and intergration of web applications and the on going administration.

See the list of Open Source Applications I support: 

 http://www.designweaver.info/open-source-web-applications.htm

Call Robert McCulloch at 619-288-9263

Open Source History

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. 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 market it.

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). While open source distribution presents a way to make the source codes 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 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 Todd Anderson, Larry Augustin, John Hall, Sam Ockman, Christine Peterson 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.

The Free Software Foundation (FSF), started in 1985, intended the word ‘free’ to mean “free as in free speech” and not “free as in free beer” with emphasis on the positive freedom to distribute rather than a negative 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.

 

 

 

 

Open Source 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 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 sort of 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:

 

 

 

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.

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

New code should be integrated 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 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.

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. Most well known OSS products follow the Bazaar model as suggested by Eric Raymond. These include projects such as the Linux kernel, Firefox and the Apache Web Server.