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