Also I want to see what you find for your cost analysis! I always like to read them.
Travis R.
[EMAIL PROTECTED] 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 alternative...
My thoughts, and my appologies for the long post.
Shawn
_______________________________________________ clug-talk mailing list [email protected] http://clug.ca/mailman/listinfo/clug-talk_clug.ca Mailing List Guidelines (http://clug.ca/ml_guidelines.php) **Please remove these lines when replying
