Professional Documents
Culture Documents
Technically, open source means software that issupplied with the original code in which it was written allowing others to view, modify, adapt, and improve this code. This can include software that cannot be redistributed without explicit permission (and often a payment) to the software owner. Most people now define open source more narrowly to as software with the following further characteristics: It is protected by copyright, but not patents. It has a copy-left license (GNU license or similar), which states that it can be redistributed for no charge, but the source code and modifications must be licensed out under the same terms that it was licensed in. Sample licenses are available at http://www.opensource.org. Please note, that it is acceptable to sell commercial software in a bundle with this open source software. Open source software is not the same as shareware or freeware which often does not come with source code and has zero cost as its defining characteristic. Open source software, may or may not be zero cost. The benefit of open source software is that when people are allowed to read, distribute, and modify the source code for a piece of software, the software evolves and gets better.
where by a corporation produces and sells proprietary software, to a cathedral and the open source model to a bazaar.11 In the corporate model, individuals or small groups of individuals quietly and reverently develop software in isolation, without releasing a beta version before it is deemed ready. In contrast, the open source model relies on a network of volunteer programmers, with differing styles and agendas, who develop and debug the code in parallel. From the submitted modifications, the delegated leader chooses whether or not to accept one of the modifications. If the leader thinks the modification will benefit many users, he will choose the best code from all of the submittals and incorporate it into the OSS updates. The software is released early and often.
The use of open source is argued to bring several benefits in comparison to proprietary developing models.1 These advantages can be economic, e.g. the reduction in research and development costs on the one hand, and technical i.e. resulting in better quality of code, on the other. The traditional argument is that open source offers the software developer increased reliability: it has been said that given enough eyeballs, every bug [in the code] is shallow.2 This means that given a large enough base of beta-testers and codevelopers, practically every problem in the code can be solved by the time of release. This is not always the case in traditional, in-house programming team constructed software packages. The OSS community admits that there can be valid cases for keeping the code closed. If considerable research and development effort is required to produce a product based on a new technology, then keeping the code closed would seem to be a plausible business strategy. They are quick to remind, however, that once a competitor comes up with a similar product, one should go open source in order to encourage the best pool of co-developers to invest time in it and thus enhance the life cycle of the product
1 2
not available if you keep your software proprietary. These can improve product quality, reduce development cost or reduce marketing cost. Examples are: Quality control and improvement. By providing your source code, others can review this and suggest improvements and give these back to you. New applications. By providing your source code, others can adapt this to applications you never thought of. Easy distribution. There are many websites (such as http://www.freshmeat.net, http://www.sourceforge.org, etc) that will freely publicize your open source product.
But enhancements may be necessary to enable integration. How do we resolve these conflicting agendas? The software vendor may contribute the once for-fee licensed software as open source to the user community. The vendor no longer officially provides support. But the customers may well still be important to the vendor, so the vendor may provide resources to incubate the project. This is a short-term commitment and the real intention is to shift support to a community of users. Besides the possibility of re-invigorating the product as a community open source project, it is possible that a commercial interest may come forward and provide support in the parallel universes model. Examples: OpenIngres, Fedora Parallel Universes Enterprise-class support (Brand Name) Software vendor piggybacks on robust open source project to provide SLA-class support to enterprises that require it or find it provides value. Examples: Red Hat Linux, Debian, JBoss, TAO. Jump Start Bleeding-Edge Technology (Embryo) vendor-created and attempted launch of a for-fee licensed software product, but unable to achieve critical mass in the marketplace. This may have been because supporting tools were not yet available or it may have been because the product was so advanced that potential buyers did not yet recognize the value. Open source effort is designed to appeal to like-minded early adopters who may not have the budget to purchase an unproven but innovative technology. Example: PXE Community Collaborative Software (Good Guys in White Hats) technologists created a solution to a known problem for their own needs and saw the benefit of sharing code, innovation, and support across organizations for the benefit of all. Examples: Apache Commons, Mule
Comparison
There are many business models for open source and each has an important and valuable role to play. It is important for an enterprise to consider their specific needs and how the business model behind the open source project aligns with these needs. It is also important to recognize that the business model may evolve as the open source project and the community that uses and supports it evolves. Open source provides an exciting channel for innovation and a fascinating array of business models. If used wisely, it can provide dramatic benefits in cost and quality. Business Integration Technologys open source strategy is to work with our customers and leverage their existing IT infrastructure where it makes sense, but to leverage open source to fill the gaps and integrate it all in a service-oriented approach.
Conclusion
Open source software can co-exist with proprietary programs. In some instances it can be more plausible to choose open code than keep it closed: ultimately it is up to the firms business strategy. In any case, the ideology of commons in the field of software is here to stay, and legislation, as well as commercial actors will adapt to it like they always have when a new way of doing business has arrived.
References
www.corp21.com/download/OS-Software www.eclipse.org/community/casestudies/Actuate_OS_Final typo3.org/.../t3n_nr9_open_source_business_models_in_tran
sition
assets1.csc.com/fr/downloads/4819_1.pdf