Apple Jam Recipes

One of my grandmothers was into making the occasional pot of jam, and it turns out that she was quite good at it. So much, in fact, that everyone thought she had some sort of secret recipe - but when people overcame their shyness and asked, she would practically deliver an essay on the subject.

You see, she swapped recipes with her friends, and the recipes gradually accreted into a body of knowledge concerning the best time to pick the fruit, how long to boil it (or not), how to cut (or enhance) the tartness with blends of cinnamon and aniseed, etc., etc.

So it wasn't just the recipe or the raw materials, it was the knowledge involved - even if the recipes were Open Source, there was always a considerable amount of know-how that stayed with the cook.

Purists may say that the recipe/algorithm ought to be detailed to the point where all the knowledge required is included, but I'll just point them to this post on the GIMP file format. If you can give me a plausible justification for that kind of idiocy and why this is supposed to be the "documentation", I'll switch to the GIMP and save all my stuff as .xcf.

As an engineer, I like Open Source because it lets me gauge the quality and design approaches of a system or tool, and as a hobbyist I love it because it lets me tinker with things and make them work the way I want to.

But as a project manager (and part of a product/service management and integration chain), I want someone accountable for maintaining it, fixing the bugs and delivering something that satisfies whatever requirements are set for it.

And the very same thing applies when I'm a customer, regardless of whether the software is Open Source or not - which is one of many points that need to be made where it regards and the ongoing debate about "Un-Switching".

The Silly Minefield

In the aftermath of Mark Pilgrim's switch to and the short series of between himself and John Gruber, Tim Bray's assertion that he, too, would eventually switch away from the caused an interesting interference pattern in the ripples - now we're back discussing whether Apple should Open Source its applications, at a time when:

  • 6.06 LTS is making a lot of waves.
  • Gnome is, by most accounts, as usable on a desktop as Windows (which is what most people know).
  • The world is going through a PowerPC-to-Intel transition that is starting to look like a reprise of the 680x0-to-PowerPC switch from years back - but this time, with a lot of noise regarding hardware issues, Intel virtualization, even (gasp!) running Windows on a .
  • There are still some mysteries around Xnu (the Intel bits of the kernel).
  • Stuff like occasional licensing conflicts where it regards integrating tech with Open Source (or the other way around) keep re-surfacing.
  • Summer is peaking (and you can't deny that Summer is a "silly season" in news and technical terms, with most people taking a break and taking things more lightly).

All of these are mostly noise and tend to muddle the relevant issues.

To me, the relevant issues are centered on Open Formats, but the Open Source aspect is a valid (and juicy) one, and to John's credit, he supplies us with a very thorough breakdown of why Tim's concern about 's applications not being Open Source won't turn the tide.

But I think there is a flip side to the coin.

Jamming The Radar

I keep wondering if Mail.app (for one) wouldn't be considerably better if its core bits had half the exposure that WebKit has, or if iChat would have had a chance to evolve to become the standards-uncompliant mess that it is if it were based off or, better still, the odd-named application that replaced Gnomemeeting.

I have a feeling that they would at least be more interoperable with other stuff, which entails having the decency of supporting IMAP IDLE and SIP/H.323 properly - and hopefully causing considerably less pain to their users.

And these are just two examples. I can open my Applications folder, go through every binary in there and point out similar issues in every one of them - with the laudable exception of . Most of the rest of the Utilities folder is also pretty well rounded out, but then again they're too specific to be of consequence in this context.

What really bugs me is that even the day-to-day tools are flawed. For instance, the has egregious (and historical) that would put Nautilus to shame (and I'm not even that fond of Nautilus), and that have caused me to become more acquainted with Radar than I really wanted to.

And no, 's applications are not Open Source, and there is no real prospect of they ever going down that road - but in the same way that I, as a customer, expect things to work according to my requirements (and I accept that my requirements may not be wholly met by 's bundled applications) I at least expect the more glaring flaws to get fixed (and no, I won't mention anymore...).

Feature Creeps

And that applies to run-of-the-mill features as well (i.e., those that have become trivial in like software). For instance, I take particular exception to the example of iChat's next version having tabbed chat windows and being exclusive to , especially when Fire and had such features (and more) for such a long time. That's not a selling point, it's hoodwinking your customers.

Of course, customers have the responsibility to make informed decisions - which is, so far, precisely what Mark Pilgrim and Tim Bray are doing. If they are (or, in Mark's case, were) not the kind of users that lined up around the block for a midnight release party, well...

Such people do exist, and, when they have the gift to get their point across, they tend to be opinion-makers.

Recipes and Cooks

It's easy to think along the lines above. Perhaps even dangerously so.

After all, when you're exposed to all the going around and have a strong background, the mind just slots into the groove and slides down well-oiled pathways according to your predisposition - if you like Open Source, you'll go one way, if you have qualms - which Zealots will instantly perceive as you being against Open Source - you'll go another.

And, of course, if you prefer Open Formats or care about your data outlasting your platform, you'll face the kind of hard decisions that Mark and Tim are facing (and which I, too, have recently).

But, like with my grandmother's lore, it's easy to forget that making the kind of "jam" we're discussing does not necessarily improve with opening the source.

After all, there is a phenomenal amount of know-how locked away inside that will simply not be part of any hypothetical recipes that get shared - not in the sense that WebKit isn't exactly (or , or the other uses of it inside ), but in the sense that there's just too much knowledge to convey.

I remember Inside Macintosh - I had a copy of it on my desk, many years ago, in my MPW days, and back then you could conceivably hold all of it in your head and know all there was to know about the .

These days (some fifteen years since I first saw IM), is a couple of orders of magnitude more complex, and the fact that it has underpinnings is more than a bit misleading - people assume that just because you can easily port most Open Source software to it, it ought to be the same.

Well, just because it looks like a duck from a certain angle doesn't mean it is a duck. In several aspects where quacks, sings - and not just on the UI front. The user chorus may have gotten a bit shrill of late, but can still carry a .

I just hope that's not the only thing they're concerned with.

This page is referenced in: