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