What is the difference between FREE, Free, and free? You’ll rarely see the lower-cased version in marketing, rarely see the all-caps one in prose, and the one in the middle is downright tricky.

There is such a plethora of meanings and implications associated with this common word, that it may be due the same awe-inspired analysis its naughtier, equally versatile 4-letter cousin often receives.

The Oxford English Dictionary lists several entries for the word, divided into a number of word types: adjective, noun, adverb, verb, and combining form. In total, over 40 definitions. Fortunately, for the purposes of this entry, we need only be concerned with the definitions that apply to software development and computers. Unfortunately, this arena is a microcosm that exhibits most if not all of persnickety meanings of the world at large.

As it pertains to software, a great deal of analysis and refinement has already been made. The Free Software Foundation (FSF; cheesy new logo, by the way) is probably most responsible for starting and continuing the debate at its most philosophical level. Richard Stallman wisely noted in his definition of free software that a clarification on the dictionary meaning of the word was important in setting the context for his organization’s purpose:

“Free software” is a matter of liberty, not price. To understand the concept, you should think of “free” as in “free speech,” not as in “free beer.”

This distinction and his metaphors in particular have become widely used by open source software developers when attempting to clarify the terms of their own particular licenses. But I find some fault in the analysis. Free speech really is free. Free software? I’m not so sure. With free speech, I can quote somebody like Richard Stallman in a public lecture, and get paid for it. But GNU’s free software comes with conditions. I can only speak freely (liberty) if I also do it freely (cost-wise). Seems like a weird compromise between free speech and free beer. I can drink as much of it as I want, but must use their toilets when it’s time to piss it out.

Still, the metaphors are important, because they help clarify a sort of top-level sorting decision when analyzing uses of the word. Before any further thinking is done, one should determine which meaning is intended. In some cases, such as with the FSF, it may be a tricky combination of both.

It has been pointed out that many languages have separate words for the two meanings. That’s convenient! In Spanish, for instance, free as in beer is simply “gratis.” No charge, amigo. Free as in speech is “libre.” When you consider that free as in speech is one of the more debatable concepts in any language, regardless of word choice, it’s no surprise the problem runs more than word-deep. “Freedom Isn’t Free,” and neither is understanding what the freeking hell that means.

Freedom of software is in fact just like political freedom. You can do anything you want, except for what your masters restrict you from doing. In the case of Free Software, as with citizenship, we have some measure of choice in the question of who makes our rules. But it’s frustrating and pride-injuring when you believe you have the right to something, and your government insists otherwise. These ironic caveats to political freedom are among the motivations for anarchistic thinking. Perhaps the closest concept to anarchy in software development is the public domain or similar “complete freedom” licenses. Free as in speech and free as in beer. Free as in kegger, dude!

The Marketing of Free

Free has long been used in marketing to mean a variety of things. The fact is, it almost never means either free as in speech or free as in beer. It usually is used as code for some other, more complex concept, which has been massaged into some form that can very narrowly be interpreted as “free as in beer.” The idea for marketers is to make the consumer think, even if only on a subconscious level, that they’ve been blessed with a piece of property for which they had to do no work. Free as in manna from heaven.

So what does it really mean? Usually it means “no extra charge.” That is, if you give us some money for one arbitrarily priced product, we’ll throw in a second, much cheaper to manufacture product absolutely FREE! An excellent example of this are the free toys included with Happy Meals (or is it the free food included with the toys?). Along the same lines are the free stickers or games included with breakfast cereal. No, it’s not free. If it were free I could open the box, take out the toys, and walk out of the store. It’s not illegal to steal free things, but it may certainly be a crime to steal FREE things.

No extra charge can often be tricky, because you don’t realize that you’ve already paid for something. Advertisement-funded products are like this. When you watch a television show or view a popular web site, you may in fact be paying for the content merely by being exposed to the ads. Passive payment is simultaneously reviled and beloved by consumers. Most people love to hate ads, but not enough to warrant spending ordinary cash on the product instead.

Almost as often, free means “free for a limited time.” This is the ploy of companies like Netflix when they offer potential customers a “Free 2 Week Membership.” The saving grace of this use of free is that you really can get something for no money. In exchange for the likelihood that you’ll become a paying customer, you can enjoy the full benefits of membership for 2 weeks without charge. This kind of free also passes the “stealing test.” You can steal the 2 weeks. That is, you can sign up for the trial absolutely committed to not become a member later. The main questionable aspect to this use of free is that it runs out after you take advantage of it. Even though there is a theoretically endless supply of two week trials (you can tell all your friends about it), you personally are entitled to only one of them. This is “free as in one cup of beer.”

The free trial concept is widely used in software, especially now that the Internet seems to have surpassed retail sales as the primary distribution method. What used to be called “shareware,” a try before you buy approach to commercial sales, is now commonly employed by marketers at all levels of the software continuum. The meaning of a free trial in software varies a great deal, but the practical mode of limiting a trial is by time used or feature omission, or some combination of the two.

Timed trials are usually fully operational copies of the software that are intended to expire after some number of uses or a passing of calendar time. This trial is often called a “fully functional demo,” to distinguish it from a demo that does not contain all the features of the full product. Timed trials are “free as in one cup of beer.” The product may solve all of your problems or may be completely useless to you. But in any case, you are entitled to only one free trial.

A feature omission trial usually offers some subset of the product’s functionality, and is designed to work forever in this state. Depending on the degree of missing functionality, consumers might classify it either “crippleware” or “a lite version.” The implication is that crippleware is practically useless, while a lite version is so useful in its limited scope that it may be considered a product in its own right.

Feature omission products pass both the “no cost” and “you can steal it” tests. If you are happy with the product as-is, then you come out a winner. These products are “free as in Pabst.” You might wish that you could have a cup of Full Sail or Newcastle, but for the price, you’re happy to keep refilling from the free keg. Marketers hope there aren’t many people like you, or else they’ll never sell any of the product. The idea is you’ll tell all your friends about the free Pabst, but when they show up they’ll pay for the choicer beers.

Whatever the flavor, a free trial is a trojan horse that gets brand and product familiarity into the mind of the consumer. The ultimate goal is usually not to give something away (that’s not what marketers are paid for), but to improve the odds of a for-cost product being purchased in the future.

A very consumer-friendly version of the feature omission trial is one in which only one or two of the most advanced features is omitted. In this scenario, the publisher hopes that the product will appeal to a wide audience, and that the utter usefulness of those last few niggling features will be enough to win a relatively high purchase rate. The excellent weblog Daring Fireball is a combination of such a highly featured trial, combined with a small amount of advertising-based payment. The site’s owner/author, John Gruber, is currently in the midst of a pledge drive of sorts, which alludes to yet another kind of free: “free as in please pay me.”

“Free as in please pay me” is best exemplified by public television and radio. It’s absolutely free, except they’d love it if you decided to pay for it. Ironic, isn’t it? This confounding concept is known in the software world as “donationware,” and is almost universally regarded as a good way to make zero money. Public broadcasters figured this out, which is why you see and hear about “thank you gifts” during almost every pledge break in the country. John Gruber also figured this out when we decided to start including (selling) T-Shirts at a certain membership rate. As he says, “People will happily pay for things they can actually hold in their hands, but you can’t touch ones and zeroes.”

The Edge of Freedom

Another type of free product has become very popular lately on the Internet in particular. The “business plan will emerge” variety of free products and services offer “free as in beer” goods with apparently no strings attached. In fact, the analogy to beer may finally be appropriate here. On some level, the providers of these mysteriously free products are hoping to get you addicted. Once you find yourself unable to make it through a day without them, you’ll be prepared to spend money or click ads, whatever it takes to avoid losing your fix. Because the nature of this freedom is very much about taking the consumer on a trip from the present “no cash” to the future “tons of cash” scenario, I’ll call this type of free software the “free ride” variety.

The goal of these companies and individuals is to obtain market saturation, and charging nothing is the surest way to achieve that goal. The business savvy of entities practicing this runs the gamut, and some of the people who make great examples may not even care that they managed to conquer an entire market. On a very macro view, the “free ride” can be looked at as a form of “free trial” or “lite version.” The difference is that the for-pay version of the product simply doesn’t exist yet. In this sense the makers and marketers of these types of products are playing a kind of futures investing game with the public, betting on free products becoming profitable through sheer popularity and omnipresence.

A good example of this on the Mac is the personal productivity utility, QuickSilver. It doesn’t matter that the product has never come out of “beta.” Almost every power-user you meet will have some familiarity with this program or may in fact be addicted to using it. What does this mean for the author? It means the entire Mac market is poised to pay for either a “for-cost 1.0 release” or a completely separate product possessing the now-valuable brand. The author has bought himself notoriety and recognition from the Macintosh public, by giving something away for free.

Open source projects are often “free ride” projects in their marketing to the public. While the user never loses the ability to use the product for free, the product itself becomes increasingly more valuable to the owners as its popularity increases. Take Firefox, for example:

The award-winning Web browser just got better. It’s free, and easy to use. Join the millions of people worldwide enjoying a better Web experience.

Why is a free browser marketing itself so aggressively? Partly, no doubt, as a test of success. It just feels good to make progress and have people use your product. But it was recently pointed out that Firefox must be making a fair amount of cash from their default Google search bar (it was speculated they made more than $70 million, but a Mozilla board member refuted that exact number). In any case, I think it’s fair to say that Firefox is making Mozilla money. From a user’s perspective, I think this is fine. If it helps development of Firefox to continue, I say more power to them!

Go Free Yourself!

From the developer point of view, there is a real dilemma raised by the free ride approach to open source. Because some open source projects are inherently valuable, sometimes even by their mere existence as a defensive measure, it’s in some (rich) companies’ interests to keep them well-funded. The distributed nature of open source projects means that your “coworker” on a given project may be making considerably more or less than you. While this is true in any job, there are no companies where the lowest paid contributor makes nothing, while the highest paid makes six figures. If I was working at such a company, I think I’d have a gripe with management!

It strikes me that the increasing involvement of commercial companies in open source projects may spell both their salvation and their doom. Human nature would seem to dictate that giving labor away for free is only fun until you find out that somebody else doing the same thing received a Mercedes and a house in exchange. Does the fact that highly paid engineers from heavy-hitters like Apple, Google, and Sun, are regular contributors to several major open source projects threaten the ability of those projects to recruit free labor from the public at large?

Perhaps an open source project will naturally lean towards being completely free-funded or completely salary-funded, based on its perceived value by the businesses of the day. At what point does making the decision to work on a project like Firefox mean deciding to search for an employer willing to pay you to do it? You want me to work on that for no pay? Go Free Yourself!

The Truth Will Set You Free

Unfortunately, this little writing excursion of mine has only scratched the surface on the meaning of free and how it pertains to software and our lives. This is an example of fairly unstructured, unresearched work that I’m presenting to you for free (free as in my speech). The fact that it’s also free (as in “free ride” – hopefully I’ll become part of your blogging addiction – and “please pay me“) means that I have certain editorial freedoms (this blog is “management-free!”). I choose to stop writing now. I’ve used enough of my “free time” as it is.

I hope you’ll consider carefully the meaning of free in the contexts where you encounter it. Customers should ask themselves, “How am I really paying for this?” Marketers and developers should ask themselves, “What do we hope to gain by giving this away? What does it mean that we’re giving this away?” And remember: There’s no such thing as a free lunch. Unless you work at Google.

Update: Wed May 10, 2006, 11:00PM EST.
Writing this entry and then re-reading it inspired me to revisit some GNU free software writings. I think my argument stated above that I couldn’t quote somebody and get paid for it, is flawed. The fact is that GNU requires certain conditions be met, and money is in most instances not relevant. You can sell the software for as much as you like, so long as you provide source code to substantiate the underlying “freeness” of it. I apologize the momentary ire this might have incited in any readers. I’m glad i caught it before anybody complained!

I got sent down a path of nostalgic code review today. After spotting Wouldja Software’s RoboNuts, I couldn’t help but wonder if the source to my implementation of the same game from more than 10 years ago was still on my computer. I was beginning to think it was lost forever to some floppy disk backup at the bottom of some storage closet, but sure enough Spotlight found it!

“Super Robots” was the game I “got my feet wet” in Mac programming with. I had just gotten my PowerBook Duo 210, and coming from a UNIX background, was still really addicted to the libCurses based robots game. I was also really impressed with ResEdit and the ability to set menu colors, etc. I think I exploited every possible ugly UI feature in the design of this game. Wow. Embarrassing. It didn’t help matters that the Duo 210 was a monochrome (grayscale, actually) machine, so all of my graphics were sort of guesses at what might look good on a color screen. Oh yeah, and I’m not a designer. Clearly, localization was not a major consideration, as all of my instruction screens were PICT resources such as the following snapshot:

My coding conventions were still clearly suffering from UNIX culture.

/* robotMvGfx.c */
/* robot game movement and graphics functions */
/* Robots (C) 10/93 Daniel C. Jalkut 		*/

Yeah, the file is called “robotMvGfx.c” – short, I presume, for “Robot Movement and Graphics.” I’m sort of baffled by this design, but looking closer at the source file it might better be classified as “almost the whole darned app in one source file.” In addition to code for loading and plotting the graphics (icon resources), there is logic for all game movement, for reading and writing the high scores, and for double buffering the game display into a GWorld before flushing to screen periodically.

I remember shortly after releasing Super Robots, getting pretty instantly pummeled by dissatisfied users. I had neglected to properly check Gestalt for systems incompatible with APIs I was using. I hadn’t added much flair to the original UNIX game. I was a crappy artist. Etc., etc. I begged users to send me some money if they liked the game. I think two people sent me $5 each.

Whatever. Two years later I was working on the Mac OS System File and having a grand old time. You don’t have to be perfect, or anything close to it, to be successful. Just be willing to learn from your mistakes and get better.

I know everybody is sick of this issue. Believe me, I am too. But for the people following along from home I feel obligated to keep you posted on this until it reaches a resolution. Here is the latest chapter in my experience with getting my MacBook Pro repaired.

So far my machine has only been to AppleCare service once. I sent a long list of problems and hoped that at least some of them would be addressed. The machine came back largely unchanged, and now I’m trying to decide when and if to send it back. Most of the existing noise problems persist, and now that spring is descending on the Northeast with summer-like temperatures, the heat is more unbearable than ever. My hands literally get sweaty while typing on the thing! If that’s normal, then the world is due for a revision to laptop design. I bought the Apple argument that it’s “not a laptop.” But if it makes my palms boil there isn’t much I can do for that short of using an external keyboard.

I finally got up the psychic energy to call AppleCare back. It’s always hard to make these calls, because you have to steel yourself against the inevitability of them trying to convince you again that the problem isn’t really a problem. Yeah, OK. But anyway this time I got put pretty quickly in touch with a “product specialist” because my complaint was that a repair had come back with symptoms unfixed. To be honest, I was expecting most of the problems to be unfixed. But I didn’t expect the “display buzz” to still be there! That’s the one thing they had expressed confidence about fixing. I had agreed to send my machine in, and be without it for more than a week, so that I could at least get the display buzz fixed. I figured, if I had to suffer all the symptoms that everybody else does, at least I want to get the part that’s fixable fixed.

So now that Apple wasted a bunch of money on shipping and labor just to send me a machine nearly identical (except with the hard drive wiped) to what I’d sent them, I’m more than a bit hesitant to send it back off for another round of attempts.

To their credit, they claim that this time around it will go to a “higher level” of service. I guess that means somebody capable of actually repairing machines? I don’t know. It seems like it would have been worth it, sometime around when they were reformatting my hard drive, to also turn on the machine and see if the one symptom they were sure they could fix … was fixed. At least then I’d only be complaining about the CPU whine and the mooing. And I’d have a somewhat improved user experience (to be fair, they did manage to fix the “high pitched squeal” through some luck).

I’m pretty close to just accepting the flaws of the machine that may not be fixable. We may all be stuck with CPU whine and mooing. OK. If we’re all in this together, I think I can deal with it. I’m not happy about it, but I can deal with it. I’ll refine my QuietMBP application, embrace the udder cowness of my machine, and wear oven mitts or something while typing.

But I want the buzzing to go away! At least!

Now I’m faced with the prospect of going through all that “sending it in” garbage again, hopefully this time with a semi-joyful resolution at the end. But being without the MBP for that week and a half is damaging to my productivity. The very act of choosing a “least harmful time” to send it back in is stressful, and I’m liable to make the wrong choice, and end up wishing 4 days in that I had it available for Intel testing or portable use.

I’m going to think about it over the weekend and decide on Monday whether and when to send it in again.

Update: I meant to point out that there is a loose plan to do a launch a mass complaint against Apple in particular about the CPU whine problem. It tickles me pink to see any mobilization at all on the issue, so I am supporting the cause. But I don’t really care when you call, as long as you do call. One of the things that bothers me is that some people are running my software to workaround the whine, and therefore not complaining with Apple about the problem. I was guilty of this with the PowerMac G5 whining problem. I was just too busy and depended too much on my computer to let it out of my hands for a round of attempted repairs, so I never called.

If you have the whine and it bothers you, it’s imperative that you at least let Apple know once that the whine is bothering you and you want it fixed. If you’re not ready to send it in, at least call up and complain about the problem. Tell them you can’t send it in yet but you want to open a case for it and will think about when you can find time to send it in.

To encourage vocalization about the problem, I wonder if some kind of “I Whined” badge might be helpful? If there are any graphic artists reading this who would be interested in donating your time to whip up a quick graphical badge suitable for web display, let me know. If we can get people to place “I Whined” badges on their sites after calling Apple, then it might encourage others to do the same. I would also be willing to set up a page here dedicated in particular to the whine problem. Then users could have the badge point at that page for more information.

Just a thought. We can’t take this lying down (with our hands over our ears).

It’s been a while since I’ve complained about Apple in the context of an actual bug report, so here is a little diversion back into “Apple Bug Friday” land.

One of the aspects of Mac OS X programming that can really frustrate traditional Mac OS programmers is the lack of error reporting from many APIs. While traditional Carbon APIs tend to return numeric failure codes when something goes wrong, it’s not unusual for CoreFoundation and related APIs to simply return NULL. What’s the developer to do in this case? The usual argument is that NULL is returned only from functions where a more specific error would not help the programmer convey meaningful information to the user. In other words, if it returns NULL when you don’t expect it to, your computer is either melting down, or you’ve got some debugging to do. Regardless of the validity of this argument, it can be infuriating to look at code that seems perfectly correct, and be clueless as to why it is failing.

I was chatting with Jonathan Wight when he shared his frustration with the CGBitmapContextCreate function. He was in the midst of debugging just one of these mind-boggling NULL returns. All the parameters looked more or less correct but the function just plain refused to cooperate.

I guess I was between builds or something because I got interested in the problem. While Jon took the more efficient path of carefully examining the parameters being passed and comparing their values to the documentation’s restrictions, I started traipsing through assembly in Xcode. You know, the fun stuff.

Of course, Jon found the answer first. It was a problem with the combination of colorspace and alpha parameters. The limitations are well-documented (if a bit overwhelming) in Apple’s Technical Q&A. In this case, Jon was fetching the values directly from a CGImage that had been loaded from disk. Can’t blame a guy for thinking that maybe a JPG image’s attributes might be suitable for creating a bitmap context!

Even after the bug was resolved, I continued digging into the framework via the debugger. I’m due for a complete retraining on Intel, but as long as I have my PowerPC machine around, I’m fairly comfortable zipping through the various API to see what really happens when an error occurs.

Sure enough, a few levels into the API, I spot an examination of the input colorspace, and an objection to the fact that it was only 24-bits per pixel. Great, I thought. If the API knows exactly what’s wrong, why doesn’t it let us know somehow, at least through a logging message or something. Then I spotted a call to “CGPostError.” Well, that’s interesting. A well-defined error reporting mechanism? The results of which the developer never sees? I traced along a while until discovered myself in a logging function, the parameter to which was this choice bit of text:

CGBitmapContextCreate: unsupported parameter combination: 8 integer bits/component;
	24 bits/pixel; 3-component colorspace; kCGImageAlphaNone.

Well! It doesn’t exactly point to the right solution, but it would have been nice to know! Thanks for not sharing, CoreGraphics. Why the heck does it go to all this work and not print out the result? I decided to dig deeper.

The framework has an internal function, “hasTerminal,” which seems to control whether logging to the console occurs or not. I guess the engineers on the CoreGraphics team are trying to be considerate and not spew logging messages all over your console log unless you’re actually, you know, debugging. Here’s the kicker – hasTerminal returns true if you are running from the terminal. All Jon had to do was test his app from the command-line and the exceedingly helpful logging message would have appeared.

But the “hasTerminal” function returns false when debugging from within Xcode. Bugger that debugger! How does hasTerminal decide whether to allow logging or not? It simply attempts to open “/dev/tty” with read/write access. If it is successful, the user must be running from a terminal? But somehow, when running from within Xcode, this test fails, and therefore logging is not done. I assume this has something to do with Xcode’s magic terminal-esque window, but the discovery raises two questions:

1. Should CoreGraphics limit its logging functionality based on assumptions about “/dev/tty”?
2. Should debugging in Xcode impact a target application’s ability to open “/dev/tty”?

These questions are posed in Radar #4538344– “CoreGraphics logging doesn’t appear withing Xcode”.