Nov 2007

Facets of Open Source Part I

Recently I was asked the following question:

What is the point of differentiating Open Source as an entity versus something that has just always been there?

In other words; if a company sells services and products, what reason outside of buzzword compliance is there for creating a practice that revolves completely around Open Source?

Good question - the answer is simple at first:

Open Source is more than just software - it is a way of doing things - not to be confused with best practices. Open Source is a pragma versus a method.

It is easy for people who do not live with Open Source to become confused. The larger the distance from Open Source (for instance - persons who are only business oriented) the greater the confusion [1]. This text examines what benefits of Open Source can mean while the next article will use specific real world examples of Open Source saving time and money.

What Does it all Mean?

Open Source and indeed Free Software are not necessarily free of cost. It is free in the sense that the code is available, may be modified for local use and redistributed as long as the original license remains intact and is adhered to. In some cases, upstream patches of changes are required. So what does free really mean? Truly free is the definition of Public Domain - or do whatever you want with it. [2] So where is the cost?

Where a product can be bought and brute force implemented, talent can be purchased and used with accuracy. The entire idea of service versus product is key to Open Source. Only a few years ago, most companies looked at software as a boxed product to buy: direct system administrators and database administrators to put the product in place; then let users and/or developers have at it. The problem of course is that computing systems are organic at some level even if they do not appear to be at a high(er) level. Computing systems evolve; even if the underlying hardware and software use extraordinary mechanisms for release/change control - the evolution cannot be stopped: the reason for this is simple; stop evolving the systems and you will lose. Changing the thought process from blackbox product to strong resources makes sense. Open Source is an enabler of the idea that powerful resources give advantage as most Open Source is is inexpensive (or free) to use, allowing an organization the financial resources to pay for resources.

What is the Cost?

Is it possible that the costs even out? Certainly. The real answer is it depends. It truly depends upon the type of software and scope. A good example is to compare the difference between three different software system types in an order of magnitude:

  • Compiler toolchain.
  • Database products.
  • Operating System.

Note that the product is not the only item to consider; there are two other costs:

  • Local support/development expense.
  • Vendor support expense.

Compiler Toolchain

For those who have ever had to deal with building for multiple platforms (or target architectures) from a single platform; powerful crossbuild toolchains are a blessing ... and wrought with danger. Getting a free crossbuild toolchain is easy: GNU has a great one. The problem of course is support. A company known as Cygnus [3] used to offer support for cross compiling - there are likely more. Most proprietary crossbuild systems have a hefty front end fee plus even larger support costs. In this the smallest example; the benefit of Open Source far outweighs the proprietary alternative. For example, the cost can be less if paying for a person who has the skills to master the toolchain versus buying an off the shelf product with some sort of support agreeement.

Database Products

Databases have one main factor: scale. A proprietary database product - top of the line - can come with a rather large (on the order of thousands or even tens of thousands of currency) front end fee before licensing and support are even factored in. If a database does not need features like built in database redundancy (outside of the OS) and will not exceed a few million rows in any given table then there is no reason to sink thousands into closed products at all. Some of the open source products are not only catching up with features like built in redundancy and a multitude of multiplexing access methods, in some areas, they are exceeding their closed source counterparts. This makes the support side easy, with no heavy front end cost; database specific support through a vendor for an open source project is trivial. Conversely, if there are features in the proprietary database that are needed - then that is the way it is ...

... just remember; the Open Source equivalent may be available next year ...

Operating Systems

A complete operating system is entirely different because of support models. Some companies will support software on the operating system in addition to the core OS - which muddies the water a bit. For the time being, things like development and database software will be tossed aside within this context to look only at the core Operating System.

Most, not all, proprietary operating systems are tied to a specific set, class or even their own hardware models. The same can be said of open source operating systems - the difference being the former is a complete product line while the latter is something one can deploy with more flexibility on a particular group of hardware platforms; in some cases - a large variety of platforms.

With most supported Open Source operating systems, there is some sort of fee associated with support and subscription. Support and subscription are also tied to proprietary systems - the difference is the cost (Open Source systems are generally- but not always - less) and hardware. With many (not all) closed systems the hardware is either the same company or a very limited set. The offset cost of open source is dealing with multiple hardware vendors and their support structure. It is worth noting that most Unix shops deploy a mix of vendors anyhow - so the old argument of one vendor for all is usually the exception.

The operating system is probably the fuzziest area of support because of the multitude of factors involved:

  • Subscription fees (patches etc.)
  • OS Support Fees.
  • Hardware support; singular or multi-vendor?

In the simplest case, general purpose, large (not very large) database, distributed or commodity systems are best served with Open Source. Only exceptions to the rule apply to closed systems. It is worth noting that this is a complete reversal in thinking dating only a few years ago which stated Open Source is good only for commodity systems.

Summary & Next Time

For the unintiated getting the Open Source model is not easy; but what change in organizational practices is ever simple? A friend once said There is no such thing as simple surgery - the same applies to trying to grasp a new practice model - it is never simple.

Next time, a short discussion on Open Source models less licensing and three real world examples of leveraging Open Source for fun and profit.


  1. That is not to say the converse is false.
  2. Public Domain has its place, I use it here for snippets of code.
  3. Cygnus was one of the first Open Source service companies. They are now owned by Red Hat.