Apple and Open Source

As almost everybody reading this knows, Apple has decided to release some of the source code for OS X Server under an Open Source license, a project code-named “Darwin.” I’m sure a large percentage of the people reading this, however, are wondering if they should care. I’ll try to explain what Open Source is, what Apple hopes to gain from it, and who else might benefit from it.

 

 
What is Open Source, Anyway?

Unfortunately, Open Source can depend on who you ask. Even within the Linux community, which is most closely associated with Open Source software, there’s disagreement as to what constitutes true Open Source software (witness the various diatribes and responses to the announcement of Apple’s Open Source effort). In the simplest terms, Open Source is the set of rules under which the writers of software and operating systems release the code for their software. Its conditions govern what other users can do with the code, and how their changes can be used and published. What these conditions are is what tends to cause the controversy.

 

 

Perhaps the purest form of Open Source license is the GNU license. In brief, it requires anyone who uses the code for any work, private or commercial, to release any modifications they make to the public under the same license. As a result, anyone with access to the appropriate compiler can build the code into useable software. That’s worked great within the context of freely distributed software (such as Linux), but there are some issues when it comes to its use in commercial software. For example, when Netscape decided to release the code for Navigator to the public, it had to carefully work around code licensed from other companies that hadn’t released their code to the public. As a result, Netscape released their code under their own licensing agreement.

 

 

Apple’s situation is even more complicated. Although it’s not clear how much of previous Apple technology is included in OS X, Apple has licensed all sorts of software in the past, and so may face some of the same issues Netscape did. Unlike Netscape, though, it’s trying to sell the product that it’s releasing the code for. Therefore, the release agreement for the source has to include the ability for Apple to use any improvements or bug fixes made by others within software they sell under a strict licensing agreement. Finally, many components of OS X Server, from the kernel to the web server, was originally released as Open Source, and Apple has to work around this license.

 

 
What’s Apple Open Source Look Like?

You can read the Apple license for its source code here. In addition to the usual Open Source terms, it requires anyone who makes modifications to Apple’s code to notify Apple of the changes they make, and there’re a few clauses designed to protect Apple from copyright violations. These extra conditions have caused them the most grief; complaints ranged from the concern that Apple might cease to exist and therefore be incapable of being notified, to more realistic concerns about the nature of copyright disputes that would allow Apple to invalidate a user’s rights to the source code.

 

 

Also an issue was the limits Apple placed on what code to release. Instead of providing the instructions for the entire operating system, Apple restricted their release to the code for the kernel and some of the UNIX software that was packaged with it (you can look over what’s released here), keeping the code for the user interface out of the public domain. This keeps anybody with the appropriate compiler from building the whole OS, preserving Apple’s revenue and control. It can be argued, though, that Apple’s primary contributions to computing have been in the area of the User Interface, so looking at their code for it could be very informative.

 

 
Who Does This Benefit?

Apple. They can benefit in a variety of ways, not the least of which is association in the press with one of the more interesting current trends in software. The other intended benefits, however, will require that a productive community forms from people using the code. The main reason that Linux has become such a significant force in computing is that it has attracted a large, skilled, and dedicated group of programmers, ensuring that bugs are squashed and new features are added with great frequency. Apple has to hope that a collection of dedicated Mac programmers, ex-Nextophiles, hobbyists, and students will coalesce and use their code productively

 

 

This is in no way a certain thing. If it does occur, however, Apple may get any number of the following:

 

• Bugs fixed for free, which will allow system upgrades to focus on adding new features.

 

• Support for more peripherals, even if their manufacturers have never even seen a Mac.

 

• Free ports to other processors and/or architectures.

 

• System code optimized for specific tasks, from serving through desktop publishing.

 

• System level support for emerging technologies.

 

• Add your own point here; there are undoubtedly many I haven’t thought of.

 

Linux Users. The current releases of Linux for the Mac, LinuxPPC and MkLinux, can both benefit from the release of source code. Each time Apple releases updated hardware, the folks at LinuxPPC have to spend time and energy sorting through it and altering the kernel so that it recognizes and works with the new configuration. If Apple releases the entire Mach kernel code, this should include the necessary hardware support information. More directly, MkLinux uses the same mach kernel that the non-server version of OS X will, perhaps allowing for more direct use of what Apple releases.

 

 

The benefits do not end there, however. To make their Mach-based system useable by today’s Mac users, Apple’s going to have to overcome two of the most frequent complaints against Linux: its complicated directory structure which makes managing it too difficult for non-gurus, and the primitive user interface of its desktops and programs. A functional UNIX system depends on a strict and complex directory structure; moving a critical file or changing its name will often bring the entire system to its knees. This sort of behavior is antithetical to today’s Mac users, who expect to be able to organize programs and data any way they see fit. If Apple alters their kernel to bring it in line with OS 8’s user customization, the code may allow other flavors of UNIX to be modified in similar ways. Apple is also including many standard UNIX utilities in OS X Server and is releasing their source code. It’s likely that either Apple or an OS X user will then eventually make a decent interface for these (and other) utilities.

 

You and Me. Although most of us are not likely to muck with the source code, there are definite benefits to the possibility of bug fixes being available immediately, as opposed to waiting for Apple to do a new system release. Many of the Open Source utilities that are or will be ported to OS X have a 20 year history of refinements while running on other forms of UNIX, and will no doubt be helpful to some current Mac OS users. And, in the end, it’s also a good thing to have Apple ahead of the curve on what may be a major trend in computing.

 

 

Fine, But Are There Risks?

 

Would I have brought this up if there weren’t? Apple’s already taken some bad publicity on their licensing terms and the limits on what they’ve open sourced. Depending on how things develop, there may be a continuing stream of bad publicity. There are also dangers to both the success and failure of the program. If it succeeds in generating a community of developers, engineers at Apple may have to waste lots of time poring through poorly coded submissions produced by amateur enthusiasts. If it fails, expect more bad publicity about Apple pursuing-and then dropping-another grandiose operating system strategy.

 

 

 

Overall, these risks are almost certainly worth the potential benefits of this attempt. Still, Apple will have to move aggressively to encourage developers to contribute, help organize them to minimize duplications of effort, and focus people on areas of maximal return. So far, however, nothing’s been posted on the Darwin site to indicate any effort of the sort is in progress. Nothing new has been posted there since mid-March, when the original program was announced.

 

 

Looking through Apple’s mailing list archives at the Darwin-develop list gave me cause for both optimism and concern. The concern comes from the fact that: everything feels hastily thrown together; the source does not include device drivers, it can only currently be compiled by people who already own OS X Server; the source as it exists doesn’t provide for a user interface even if it’s successfully compiled; and there seems to be only a couple of Apple employees reading the lists.

 

 

Still, as I said, there remains room for optimism. The Apple employees who wrote in were pointing out what other code was likely to be released soon, and which of the suggestions of people writing in were worth considering or adopting. Most significantly, however, it appears that despite all these limitations, people are trying to work with the source code. Several postings even detailed attempts to get the kernel to compile on Intel-based Linux systems. If Apple gives these people just a little more help and some more code to work with, Darwin could really take off.

 


Jay Timmer
jtimmer@tuna.net

Leave a Reply