I also wrote a different take on Gruber’s back porting worries, and the fear that Apple would lose significant sales from open source competition: the problem really isn’t about money or lost revenues, it’s the effort required, as you point out.

CNET’s Charles Cooper Strikes Out in iPod Attack
There’s a common misconception about what it means to be proprietary. Here’s a disassembly of one of the worst articles yet on the subject, written by CNET’s executive editor, Charles Cooper.

Open Source Values and the Peanut Gallery
The value proposition involved in choosing an open source strategy, and a roast of the emerging peanut gallery who are attempting to hijack and betray the free software movement.

BSD and GPL: Different Sources for Different Horses
The benefits and the motivations behind two very different styles of open source development: the BSD style license, pioneered by UC Berkeley and MIT; and the GPL invented by Richard Stallman, the founder of the free software movement.

The Revolution Will be Open Sourced!
Over the last decade, every player in the software development industry has been dramatically affected by an open source revolution. How will Apple adapt to fit into this new world? Are they leading, following, or falling behind? Do they stand to benefit from an increased adoption of open source practices, or will they simply have to change how they do business?

Apple and Open Source… Strange Buffaloes?
Tim Bray’s “Time to Switch?” and John Gruber’s “Why Apple Won’t Open Source Its Apps” both discuss the potential risks and benefits Apple would face in open sourcing their consumer applications. Here’s my take: Apple does not make fierce profits from $130 Mac OS X retail sales, and there isn’t a conspiracy behind new apps not working on an old OS.

The ‘Mac OS X Closed by Pirates’ Myth
According to the proponents of this myth, Apple has abandoned their open source initiatives as they move to Intel, because they are afraid that, armed with the Darwin source code, pirate 3lit3 haxx0rs will p0wn them and have Mac OS X running on generic PCs. They’re wrong, here’s why.

In other words, ID’s actions have no relevance in this discussion.

* Going through the effort, whether you ever release the code under an open-source license, will dramatically improve the quality of your code and help protect your organization from legal challenges (patents and so on). It will require a lot of effort. You may want to perform the work incrementally.

* If your code ever gets out into the public, having clean code can help preserve your organization’s reputation. Remember when Windows source code got into the wild? Like or dislike Microsoft, it is not good for public relations when newscasters are describing how much profanity lies in your source code.

As a more important reason, having your software available under an open-source license acts as a form of protection for your customers’ investments in your firm, especially in the long term. Companies come and go. Even companies that remain may decide to no longer support a product or even remain in the same industry segment. It may not be worth the company’s efforts to continue to support the product, but it may well be worth your efforts to keep the product working in your environment.

If the crucial software for the product is available under an open-source license, then you have a much better chance to keep the product going for your environment.

I find I am much more likely to purchase a product for which I think there are options for long-term support, even if the company, for whatever reason, loses interest in the product.

Thinking long term, here are some examples of reasons why going through the difficult exercise of open-sourcing your software may help convince customers to purchase your products:

* The state government in Massachusetts has been looking into a file format called ODF as a means to be able to read documents created today years from now. The current Microsoft Word does not import files created by really old versions of Word. Without some kind of open-source product, you are unlikely to be able to read files created just a few years ago. Having your files stored in an open, unrestricted format (unrestricted by patents, the US DCMA, and so on), gives you better long-term options for preserving your data.

* If you look to purchase a music player, your choices are going with Apple’s iPod with its proprietary software and vendor lock-in, or going with the proprietary software and vendor lock-in from one of a number of other companies, most of which are unlikely to even be in the market in a few years. If you work for one of these also-rans, open-sourcing your software could help provide some measure of difference from the dominant product and could help make up for a clunky physical design and crappy software.

Each company needs to determine what it really is selling and how it makes its money. In a great many cases, the software is not what creates the revenue. The software helps create the revenue, but is likely not the source of the revenue itself. Similarly, chances are your organization has a Web site. For most firms, the Web site itself does not generate revenue. But, if the Web site looked totally unprofessional, chances are quite a few potential customers would have second thoughts of doing business with your firm.

Anyway, there may well be good commercial reasons for open-sourcing your software, especially when you think long term.

But I’d also like to point out that (re John Gruber’s post) few things further basic extensibility more than having (part of) your code out for the whole world to see (especially in the case of the system-delivered utilities).
As an example, take pre-Tiger Mail. After Tiger came out, many have tried to just keep on using the old Panther Mail.app, just to recognise that it uses private functionality in Message.framework, which isn’t implemented in Tiger. An open source app (normally) cannot do anything like that; this encourages a clearer design (IMHO). Of course, this has nothing to do with your article anymore.

Of the expenses needed to launch a project as open source, many, if not most, are sensible, good investements. You should know the IP status of all your code, you should keep it clean and presentable, etc. And it should certainly be well-documented…

Scott Steinman, I wonder if you could not have profited from taking a small fee for open-sourcing your apps. There’s nothing wrong with making money on open source this way, and perhaps people will follow up more if they make a little economic commitment as well. The poster child of this kind of release is Blender, but even small apps could probably use it… economic tools like fundable.org makes it less risky for the buyers.

Sure, anyone can toss any old code out in the public domain and call it open source… but companies can’t afford to do that. Their business model doesn’t involve tossing crap against the wall to see what sticks (well, most businesses at least.) What they publish reflects on them as surely as products they bring to market deliberately, and there has to be a positive end result for them to put the effort into creating a public version of the code.

I agree with Gruber that the best approach is to create polished public APIs for extension, and leave the core private. That gets the vast majority of the benefit that the coopt-code-compile folks want, without the pain that comes with it for those not steeped in geek.

Nice one.