Why Free Open Source Software?
The Free and Open Source Software (FOSS) model provides interacting tools, plugs ins and processes with which Geospatial Analyst (GA) can create, barter, trade software and knowledge.
FOSS GA are motivated by many factors but favouring features over quality is not noticeable amongst them. For many GA, peer review and acclaim is important, so it’s likely that they will prefer to build software that is admired by their peers. Highly prized factors are clean design, reliability and maintainability, with adherence to standards and shared community values preeminent.
FOSS community attracts motivated GA, who although frequently unpaid are much disciplined. In addition, these GA are not part of corporate cultures where the best route to large salaries is to move into management; hence FOSS GA are amongst the most experienced in the industry. In addition all users of FOSS products have access to the source code and debugging tools, and hence often suggest both bug fixes and enhancements as actual changes to the source code.
FOSS GA is motivated by peer recognition rather than a development plan supplied by the marketing department. Most want to use the FOSS themselves and they prefer robustnesss before adding features. GA is likely to consider it a win’ if they can reduce the complexity and improve the maintainability of software. Where several GA work in parallel, the best solution can be chosen in place of the only solution. Where source code is freely published and widely distributed, the users of the product will often discover and correct defects themselves.
Reliability
FOSS is relatively absence of defects, bugs, which cause incorrect operation, data loss or sudden failures. Strictly, a bug would also mean failure to meet the specification, since most FOSS projects dispense with the concept of anything easily recognisable as a formal specification. Determining what constitutes a bug is usually by agreement amongst the GA. Obvious failure to perform is easily recognised as a bug, as is failure to conform to appropriate published standards. Security related failings are clearly bugs too. Each of these kinds of bugs is usually addressed with speedy fixes. Severe defects tend to be fixed within hours of their being detected; a process wich is undoubtedly assisted by the availability of the source code. GA who discovers a bug will commonly fix the bug and then report it to the maintainers as well as issuing an updated version of the software on their own authority. Users of the software can choose whether to use the unofficial fix or wait for the official version.
Stability
In a business environment software is mostly a necessary evil, a tool to do a job. Unless the job changes or more efficient processes are discovered then there is rarely pressure or need to alter the software that is being used to assist the task. This is more or less directly counter to what motivates a software vendor who is in the unenviable position of supplying a commodity that does not wear out or age much. The vendors need a stable revenue stream to be able to keep their business going while their customers have not the slightest desire to change or upgrade any product that is working well enough to suit their needs. The objective of a vendor is to establish a virtual monopoly and then force upgrades onto there clients. In the real world, no business is static and software changes to meet new requirements. A choice to use FOSS can provide a counter to the pressures to upgrade for the vendor’s commercial purposes but cannot shelter every user from any change. Having access to the source code can allow a business to choose to support itself on an old version where necessary and gives more options and choice to the users. Putting the choice in the hands of the clients rather than the vendor.
Auditability
FOSS the source code is published is its auditability. Closed-source software forces its users to trust the vendor when claims are made for qualities such as security, freedom from backdoors, adherence to standards and flexibility in the face of future changes. If the source code is not available those claims remain simply claims. By publishing the source code, GA make it possible for users of the software to have confidence that there is a basis for those claims. Whether this takes the form of a cursory and informal inspection or more rigorous auditing, what’s clear is that without access to the source code, third party audit is difficult.
Cost
FOSS are available free of royalties and fees. Proponents of FOSS licenses tend to emphasise liberty over cost although in practice the main open source projects are free in both senses of the word. From a business perspective the purchase cost of software is only one factor; total cost of ownership (TCO) is what really matters. Potentially no need to account for copies in use, reducing administrative overhead. FOSS reduced need for regular upgrades. FOSS longer uptimes and reduced need for expensive systems administrators. FOSS Near-zero vulnerability to viruses eliminating need for virus checking, data loss and downtime. FOSS lower vulnerability to security breaches and hack attacks reducing systems administration load. FOSS ability to prolong life of older hardware while retaining performance.
Flexibility and Freedom
In a business context, software flexibility is about being able to choose solutions suitable for the needs of the users. To obtain flexibility at the architectural level, experience shows that it is often best to pick tried and trusted standards for interworking. If that is done, then best-of breed solutions can be selected for particular components within the architecture. Provided that the solutions can interwork suitably, the business should be able to avoid lock-in to a particular vendor and over-dependency. This is notoriously hard to manage, requiring a real act of will from the client. FOSS GA have little motivation for lock-in strategy. Since there is no commercial benefit to be had, adherence to de-jure or de-facto standards is typically high. Where standards for interworking do not exist, the fact that the source code is published means that proprietary data formats can’t be used to manipulate lock-in. This at least partly explains the relative success of FOSS in infrastructure areas. FOSS tends to be free of dependency on related products. FOSS offers its users greater freedom to purchase other products, avoiding lock-in to particular vendors. FOSS gives you Freedom from a single vendor. FOSS allows you to retain not just the right to use the software you already have, but the ability to continue to use it as your needs change. Freedom to modify your software. FOSS can be tailored for the way you do business. It is usually within the resources of all but the smallest companies to modify to suit their own.
Support and Accountability
Who is liable if the software doesn’t work?. A review of the End User Licence Agreements (EULA) explicitly disclaim responsibility or liability for anything more serious than defects on the distribution medium, with the responsibilities being a one-way street and resting on the client, not the vendor. Proprietary software licences are intended to absolve the vendor of liability for almost any problem you may incur. FOSS does not differ from proprietary software in this respect. FOSS licenses typically disclaim all liabilities and warranties, including such basic warranties as merchantability and fitness for purpose. FOSS GA who have adopted FOSS choose the practical benefits of increased reliablility and security over illusory options to sue or pursue other remedies.
