A FOSS project isn’t necessarily a software product

FOSS the question isn’t just build vs. buy but also borrow versus share.

Confusion often reigns over how to judge free and open source software (FOSS) as people investigate using it in their businesses. Do they use Red Hat Advanced Server? Fedora? CentOS? Should they use the community edition of the Alfresco content management server or buy the product? How does one judge the “software” and whether it’s “right” for one’s business? These are all questions that confront developers and IT managers as they encounter the FOSS world.

Searching for useful lists of criteria to “measure” FOSS can be equally confusing with the wealth of systems for rating it that exist. A useful first step is to separate the idea of a FOSS project from the product world.

A project, regardless of whether it is run by a company, a foundation, or a collaborative community in the wild, is the keeper of the software. It consists of the software, the people developing it, and the FOSS license under which it is developed and distributed. The project solves a particular problem nicely, but may require a certain investment from its users to solve that problem whether in its executable or source code form. These users would rather spend their time to get a solution than their money and indeed they may have no money to spend in the particular circumstance. For developers, using the software in a FOSS project as a ready-made building block can provide extraordinary time savings. Writing good software is hard work.

A product is something that is sold by a company to a customer to solve a problem. Money changes hands, and in that transaction expectations are set. Products are more than simply the software. They may include the ease and convenience of bullet-proof installation, tutorials and documentation, services to install or configure the product, support, maintenance, upgrades, and all the other things in the product’s ecosystem. Customers would rather spend money than time for the solution. Speed is an important consideration.

Understanding this trade-off of time and money allows one to think differently about using FOSS. Customers buy products containing FOSS software the same way they buy any other software-based product. It’s a procurement problem. One concerns oneself with questions of the vendor’s viability, their service, the ecosystem around the product, and the experiences one’s peers have encountered. You apply a proper cost-benefit analysis. One can change vendors around certain FOSS projects where many providers sell products and services, but it still perturbs the environment and IT departments never do so lightly.

Using the FOSS project instead of buying the solution ready made, one is committing to a certain amount of time and self-sufficiency, but the decision can provide excellent time-to-solution for both developers and IT architects. One colleague happily paid for JBoss while using CentOS as the underlying operating system as it fit their risk profile and vendor management style. Historically the IT question was build versus buy. To this FOSS has added borrow and share.

• CodePlex Foundation

• FOSS

• free software

• open source

• open source projects

• Red Hat