Ben Cotton is wrong about Free Software
Meteorologist Ben Cotton recently wrote an article about Free Software on opensource.com about the hidden cost of free software, but he seemed to forget that proprietary software had equal or greater cost on every line item.
We're used to hearing of software being described as "free as in
freedom" and "free as in beer." But there's another kind of "free"
that doesn't get talked about as much: "free as in puppy." This
concept is based around the idea that when someone gives you a free
puppy, that puppy isn't really free. There's a lot of work and
expenses that go into its daily care. The business term is "total
cost of ownership," or TCO, and it applies to anything, not just open
source software and puppies.
That is a reasonable statement.
So if the free puppy problem applies to everything, how is it
important to open source software specifically? There are a few ways.
First, if you're already paying for software, then you've set the
expectation that it has costs. Software that's free up front but
costs money later seems like a major imposition. Secondly, if it
happens on an organization's first open source adoption project, it
can put the organization off of adopting open source software in the
future. Lastly and counterintuitively, showing that open source
software has a cost may make it an easier "sell." If it's truly no
cost, it seems too good to be true.
Find a vendor that would sell you the Free Software.
Maybe a business from this service directory would do it. https://www.f
sf.org/resources/service
Software: Just because it's open source doesn't necessarily mean it's
gratis.
Compare the costs of the most expensive proprietary software and the
most expensive free software you can buy. The most expensive Free
software I recall seeing was HyperRogue for 10 USD, but the most
expensive proprietary software you can buy comes for hundreds of thousands
of USD.
Hardware: Consider the requirements of the software. If you don't
have the hardware that (this could be server hardware or client
hardware) you need to use the software, you'll need to buy it.
All software runs on hardware, deal with it.
At least with free software you have the right to patch it so it runs
better. Free software is likely programmed better because few
developers want to release code they think is bad. How many times have
you heard the excuse, "I don't want to release my code as open source
until the source code is cleaned up". Yes they do use the term open
source instead of Free Software.
Training: Software is rarely completely intuitive. The choice is to
get training or figure it out on your own.
I see a service directory right here. https://www.fsf.org/resources/ser
vice
The think is, a lot of people don't want to buy service for their
software because they are used to buying apps that come with service or
insurance that comes with service.
Numbers on how effective the service directory listing is would be
nice.
Implementation Getting all of the pieces in the same room is only the
start. Now, it's time to put the puzzle together.
Free Software is easier to integrate because it almost always follows
IETF standards because there is no reason not to follow them. With
proprietary software they are encouraged to protect their secrets by
ignoring the tried and true standards.
I even had someone ask me about implementing their own encryption. I
told them it was a bad idea because we weren't as good mathematicians
as the people who wrote GNUTLS or OpenSSL, and they still needed
patched for all kinds of errors because the domain is very hard. It is
worth it for everybody to pay for development of those libraries since
they are used so often. At the very least we likely know there is a
problem when everyone else does.
Installation and configuration: At a minimum this will take some
staff time. If it's a big project, you may need to pay a systems
integrator or some other vendor to do this.
That is true for all software with defaults you don't like.
Data import: If you're replacing an existing system, there is data to
move into a new home. In a happy world where everything complies with
the same standard, this is not a problem. In many cases, though, it
may be necessary to write some scripts to extract and reload data.
That is much easier to do if you are running software that the
developers had no intensive to deviate off the standards, such as free
software.
Interfaces with other systems: Speaking of writing scripts, does this
software tie in nicely with other software you use (for example, your
directory service or your payroll software)?
This is the second valid point. Free Software would be less likely to
have interfaces directly to a proprietary system unless the system was
using an IETF standardized protocol. There is little intensive for
proprietary software sellers to risk people having an easy way out.
Customization: If the software doesn't meet all of your needs out of
the box, it may need to be customized. You can do that, but it still
requires effort and maybe some materials.
That is a point in favor of Free Software because you always have the
right to customize it yourself or with any employee, contractor, or
vendor on your behalf.
Business changes: This new software will probably change how your
organization does something—hopefully for the better. However, the
shift isn't free. For example, productivity may dip initially as
staff get used to the new software.
That is aways true. I guess the point is some businesses bank on having
other businesses train people on their own internal business
processes. The notion is asinine. Only your business has your business
process, you will have to dedicate resources to train everyone on your
business. Your best best would to make it as simple as possible while
getting the tasks accomplished.
More training: What, did you think we were done with this? Over time,
new people will probably join your organization and they will also
need to learn how to use the software, or a new release will come out
that adds additional functionality.
It depends on what it is. If the software is affordable, and most Free
Software is, employees would have more chances to familiarize
themselves with it at home for their own needs.
Maintenance:
Subscription: Some software provides updates via a paidsubscription.
Patches: Depending on the nature of the software, there may be
some effort in applying patches. This includes both testing and
deployment.
Development: Did you make any customizations yourself? Now you
have to maintain those forever.
That is all software. With free software you can get your development
integrated upstream so you can save on maintenance. With proprietary
software, you are already breaking the rules so you will have to hide
your development.
Support: Someone has to fix it when it goes wrong, and whether that's
a vendor or your own team, there's a real cost.
That is all software.
Good citizenship: This one isn't a requirement, but if you're using
open source software, it would be nice if you gave back somehow. This
might be code contributions, providing support on the mailing list,
sponsoring the annual conference, etc.
You said it yourself Ben, it isn't a requirement.
Business benefits: Okay, so this isn't a cost, but it can offset some
of the costs. What does using this software mean for your
organization? If it enables you to manufacture widgets with 25% less
waste, then that's valuable. To provide another example, maybe it
helps you increase repeat contributions to your nonprofit by 30%.
It is a negative cost, also known as a gain.
Even with a list like this, it takes a lot of imagination to come up
with all of the costs. Getting the values right requires some
experience and a lot of good guessing, but just going through the
process helps make it more clear. Much like with a puppy, if you know
what you're getting yourself into up front, it can be a rewarding
experience.
The problem Ben, is a WUMBO amount of bad guessing. Programming could
use a lot more science form the development and the administration side
to keep wild mass guessing like this article at bay. It is not that
guessing is bad, but there is no reason to guess things when it doesn't
take that much time and energy to know them instead. Building large
expensive things like information systems on guesses could make you
waste a lot of time and or lose a lot of money, if not worse.
Links:
https://opensource.com/article/17/2/hidden-costs-free-software
http://www.roguetemple.com/z/hyper/
https://www.fsf.org/resources/service
https://www.gnu.org/philosophy/free-sw.en.html