WebnoteHappy is a desktop bookmark management tool from Happy Apps. Author Luis de la Rosa has focused on making it easy to quickly add bookmarks from any browser, and give them a text note and tags if desired. The application also makes it easy to import and export a variety of formats.

I haven’t used the application with a particularly large set of bookmarks, but everything seems very snappy so far. I imported my Safari bookmarks, for what it’s worth, and it was almost instantaneous with no superfluous UI to slow me down. Searching is very quick and uses a Mail-style filtering and “by what criteria” type of interface. The application also supports “Smart Folders,” again with a very Mail-inspired configuration UI.

I like the notion of an independent desktop application for managing bookmarks. It takes ownership away from browser and online services, putting the user’s archival data in their own hands. With the flexibility to export back to the browser or services, it provides an excellent compromise of full ownership of data, while selectively participating in the social communities that one chooses to.

WebnoteHappy allows user to import from or export to del.icio.us, a popular social bookmarking site. But just like NetNewsWire in its recent 2.1 update, del.icio.us is supported to the exclusion of other services. I would like to see a more generic approach taken to “bookmark sharing” from desktop applications. As users choose from a variety of services for things like blogging, they also may choose from Furl, Digg, reddit, or many other services for their bookmarking needs. At least with WebnoteHappy, the verb is “Share” as opposed to NetNewsWire’s “Post to del.icio.us.” While the latter may be more explicit in the short term, the former leaves hope for future expansion of choices – perhaps even a plugin architecture for user-added sharing support.

AppleScript support is minimal and has some rough edges (in my experiments, I managed to crash WebnoteHappy), but establishes a decent baseline of functionality by exposing the “webnote” data model to scripters who want to examine it. If future releases build upon the existing dictionary to add verbs for things like “sharing” and “tagging,” the application could take on all new levels of functionality. For instance, lets say I want to put a subset of my saved bookmarks onto Del.Icio.Us, I might adopt a system where every such bookmark is tagged as “delicious.” Then I could write a script like this:

tell application "WebnoteHappy"
	set delNotes to every webnote whose tags contains "delicious"
	set newNotes to every webnote of delNotes whose tags does not contain "dpublished"
	share newNotes with bookmark service "Del.Icio.Us"
	add tag "dpublished" to webnotes of newNotes
end tell

Such support would make it easy to periodically update arbitrary bookmarking services as I saw fit.

WebnoteHappy is a great 1.0 release, and embraces many of the design guidelines I like to harp on about (while failing to finish my own personal projects): very minimal preferences, a clearly focused problem domain, easy and intuitive to learn. Check it out!

John Gruber is annoyed by the simultaneous use of “Web Kit” and “WebKit” when ostensibly referring to the same thing. While his complaint boils down to allegations of editorial laziness, there may be a more benign cause. In any case his post opens up a can of very interesting worms.

I think the confusion comes from the fact that in most cases, when these distinct terms are used, the author is not referring to exactly the same thing. The Web Kit is a development technology from Apple. There is a tradition of calling such an aggregation of functionality a “kit.” So among all the kits that Apple provides, the Web Kit is, you know, the Web one.

The framework called WebKit is the principal code component of Web Kit, but not the only one. WebCore and JavaScriptCore are important sub-frameworks. Gruber points out that WebCore is consistently referred to with its CamelCase form. That’s because it’s a framework only. Not a kit or any otherwise loftier entity.

As programmers who deal largely in framework and header names, we tend towards using the CamelCase versions of such technology names. This habit probably comes partly from technical geekiness, and partly because doing otherwise in our code would result in compiler errors.

Admittedly, the use of umbrella frameworks by Apple prevents us from frequently doing:

#import <AppKit/AppKit.h>

But when we do find occasional to include from or load code dynamically from that framework, we must refer to it as “AppKit.” This is more than convention, it’s the law! Similarly, programmers who employ Apple’s Web Kit must cite it by it’s fundamental framework’s name:

#import <WebKit/WebKit.h>

Similarly, in my last position at Apple, I worked on the “Core Services” team. But our framework was (and is) called CoreServices. Both terms are in common use.

Let’s take a look at the primary violation cited in Gruber’s article. His snapshot of an Apple web page shows use of WebKit and Web Kit side-by-side:

But notice the (relative) consistency here. Web Kit is a concept. A big thing. It’s got a Version Matrix (caps and spaces!) for crying out loud. WebKit on the other hand is “the system framework used [on Mac OS X].” The paragraph goes on to inform developers that they can download the sources to WebKit (the framework) and build their own. By using the sans-espace WebKit nomenclature, the author communicates to developers that the framework itself is specifically being referred to.

This issue is a condensation of the difference between technical writing and technical typing. As a programmer who dabbles in both typing and writing, I appreciate Gruber’s complaint for all its pedantic charm. But these inconsistencies are welcome in my world. Programmers will tend toward using the framework name, and the situation is even “worse” than Gruber fears. He cites a few frameworks that seem less vulnerable to CamelCasing than others:

We don’t frequently see this erroneous closing-up of kit names with I/O Kit or PDF Kit because closing up their names looks bad.

But these supposed abuses are in fact common in my lexicon. I refer to IOKit and PDFKit just like that, because compilers and other programmers are most likely to understand me when I do. They are also shorter, instantly imply their singularity, and even wiki-able, if that floats you boat. I even think they look beautiful all closed up like that.

The OED lists the etymology of “caboodle” as supposedly a “corruption of the phrase kit and boodle.” So even if Gruber’s complaint proves well-founded, abusing the word “kit” is a time-honored tradition that will no-doubt be preserved.

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.