[clug-talk] Suggestions?

sgrover at open2space.com sgrover at open2space.com
Tue Mar 22 14:23:01 PST 2005

Related to Sheridan's post, I'm in the middle of a cost analysis for my own 
networks.  I'm curious to see what the price would be if I were using 
commercial products (aka non-open source).

That said, there are a couple of important points to be made here.  
The first is the so called training time.  This is a non-issue (IMO) because 
it doesn't matter if you are dealing with proprietary or open source software 
- there will be a learning curve, and the time needed will be similar for ANY 
similar technology (assuming a starting point from zero knowledge).  That 
said, once you have learned one tool, then all other similar tools should be 
a heart beat to learn - afterall, you should already understand the concepts 
involved, if not the particular methods/syntax for a different tool.  If you 
don't then you haven't really learned the tool or it's environment(s).

Implementation time is another factor.  I do not believe it is fair to say 
company X's products are faster to install than company B's.  What would be 
more fair is that Product X is faster to install than Product B.  This 
removes any bias for the company and focuses on the products instead - 
whether the products are open source or proprietary is just coincidental.  
Also, installation is usually a one time event, and should not be considered 
a factor in the usability or stability of a product.  (For example, if it 
takes me 3 days to build a server that works without need for maintenance for 
5 years, then the 3 days is meaningless.  If it only takes me 5 minutes to 
install a similar server product, but I need to expend 3 hours every month to 
maintain the server for the same 5 year period, then the 5 minute install 
time is meaningless.)   Therfore using the idea of implementation time as an 
argument for or against open source soultions is not relevant.  Using the 
idea of implementation time for a particular product might be relevant, 
depending on the situation.

The time needed to perform a maintenance task is also a poor basis for the 
open source versus proprietary argument.  If a proprietary server suffers a 
problem, the amount of time to fix this (maintenance time) with a similar 
open source server is roughly similar.  Similar tools will ALL require the 
same types of maintenance, which will take roughly the same amount of time.  
This is a subtle difference from how often maintenance needs to be done.

On the other hand is the amount of maintenance time needed to keep a service 
operational.  If set up properly, this should be similar in the open source 
and proprietary worlds.  However experience tells me that the open source 
tools tend to be more stable than similar proprietary tools, so require less 
maintenance time.  Phrased a little differently, I'm saying that proprietary 
tools become unstable more often or quicker than a similar open source tool.  
The result being that maintenance needs to be performed less often on open 
source tools.  However when that maintenance does need to be performed, it'll 
take about the same amount of time as it would on a similar proprietary tool.  
(my appologies if this seems to contradict the previous paragraph - I haven't 
yet thought this through completly, and have only jotted down some rough 
ideas here)

In my own opinion, I feel that the best argument for or against an open source 
product is 1) what gives me the most bang for my buck, 2) what product will 
have less recurring costs (such as licensing), and 3) can I get help with the 
product when needed (i.e. product maturity).  If I apply these rules, then 
most propietary tools I've used in the past (or am still using) fail the 
first two points.  A number of comparable open source solutions fail point 3.  
So for me at least, it's a balance of risks versus costs.  It just turns out 
that the risks are rarely that great.  When I do find the risks to be 
substantial (i.e. "we loose $$$$$ for every minute this server is down"), 
then the risks can be mitigated with a good development/testing environment 
before a solution is put into production - with open source OR propietary 
solutions.  If part of the testing environment is to provide failure recovery 
routines/methods and determine support paths, then most open source solutions 
will pass point 3 above.

I believe these are thoughts that will occur to most business people making 
these decisions.  They tend to fall back on what they know and are 
comfortable with - even if it costs them more in the long run.  (I think 
we're ALL guilty of this to some degree.)  Once they can see there is another 
way, they are usually willing to explore it, but will likely need some 
guidance, or at least a couple of trys at it before they trust the 

My thoughts, and my appologies for the long post.


On Tuesday 22 March 2005 21:33, Sheridan Hawken wrote:
> Hi Martin,
> Linux has everything a small business IT infrastructure needs.  It can
> be its firewall/router/VPN.  It can be the domain controller/file
> server/print server with Samba.  It can be the email/webmail server. It
> can be the web server.  It can be the ftp server.
> 	  	Windows	 		Linux
> Firewall  	$2000.00 or more	$0
> Domain/File  	$1500.00		$0
> Exchange/email	$3000.00		$0
> Web Server	$1500.00		$0
> FTP Server	$1500.00		$0
> This is the ballpark cost of windows server license and possible other
> software need for these services.  It does not include the Desktop CALs
> needed to connect to windows servers. No CALs needed for Linux Servers.
> If you want to talk about desktop then you can talk about Win XP license
> costs, CALs for Servers, and MS Office costs compared to Linux and one
> of the Linux office suites.
> My $0.02
> Sheridan
> Martin Glazer wrote:
> | Hey All,
> |
> | I'm due to give a talk next month to a group new entrepreneurs and small
> | business owners. I would like to introduce them to Linux and explain
> how they
> | can benefit from the use of open source software.
> |
> | As this will be the first talk I've given on this subject, I'm looking
> for
> | some suggestions on what topics I should include, articles I can
> reference or
> | any general hints, tips or advice
> |
> | Thanks
> |
> | Martin
> |
> | _______________________________________________
> | clug-talk mailing list
> | clug-talk at clug.ca
> | http://clug.ca/mailman/listinfo/clug-talk_clug.ca
> | Mailing List Guidelines (http://clug.ca/ml_guidelines.php)
> | **Please remove these lines when replying

More information about the clug-talk mailing list