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 withbest 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.
Footnotes
- That is not to say the converse is false.
- Public Domain has its place, I use it here for snippets of code.
- Cygnus was one of the first Open Source service companies. They are now owned by Red Hat.
systhread's
