[clug-talk] Suggestions?

Travis Rousseau travis at 802.11calgary.com
Tue Mar 22 21:36:45 PST 2005

Great post! if you don't mind could i occasionally bborrow parts of it? 
(Full credit will be given how you want ie. email address, website, or name)
Also I want to see what you find for your cost analysis! I always like 
to read them.

Travis R.

sgrover at open2space.com wrote:

>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.

More information about the clug-talk mailing list