explicitClick to confirm you are 18+

Ben Cotton is wrong about Free Software

OflameoNov 13, 2017, 12:29:04 AM
thumb_up1thumb_downmore_vert

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 paid

subscription.

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