My experience with Apple's Open Source efforts began in 2000 when Darwin 1.0 was released, and I've been involved in Apple's Open Source efforts in various roles ever since then. Apple had several Open Source efforts going at the time, with Darwin being the flagship product, accompanied by Darwin Streaming Server, OpenPlay & NetSprocket, and HeaderDoc. Six years later, all of these projects are still available. I will focus on the Darwin project, starting in 2000, since that is where my experience lies.

When Darwin 1.0 was first announced, it was released in a bootable binary form in an ASR image. Basically, this was a backup of an installed system that you restored onto a partition using Mac OS 9 and Apple System Restore, and was only available for PowerPC. The source to everything on the image was available from a CVS repository. Most of the source was 'live' in the cvs repository, meaning it was a reasonably up to date version of what developers at Apple were working with. You could see commits pretty much as they happened, and interact with the developers on mailing lists. Some of the source was not live, meaning it was placed there at periodic intervals, usually corresponding to the release of a binary image of the Darwin standalone OS. Also available at the time was nightly snapshots of the bugs, Radar entries, that related to the live sources. You could see changes as they happened, see the bugs people were working on, and interact with the developers on mailing lists. This was as close as one could come to working with the Apple developers without actually being in the office. External developers could see the problems faced by Apple developers, could see what was actively being worked on, and could make meaningful contributions. Apple began a program where external developers could gain commit access to the live cvs repository. Roughly a half dozen external developers had such access. This was the pinnacle of Apple's Open Source involvement with the Darwin project.

Not everything was as great as it seemed, however. It was difficult for people outside Apple to understand the conventions they used, and the internal processes they needed to follow. For example, it was difficult to follow what versions of which projects went into which release, and what constituted a consistent system. Building the source was also very difficult as the internal Apple build system, XBS, is very large, very involved, and was not documented outside Apple. For building Darwin standalone releases, XBS could not be used because it was proprietary and because it was just much too large and complex for an average person to use. Not all of us have a team of people and a farm of machines dedicated to just building our software. So, a system was devised that attempted to mimic XBS as much as possible. This was much smaller and easier to use than XBS, but it was still monstrously complex, and only a few people were able to set it up and build a reasonable number of Darwin projects. I believe only 1 or 2 people outside Apple have ever been able to build a full Darwin release. The few people that were actually able to successfully build a few Darwin projects and made any useful contributions to the code, were usually made Darwin Developers, meaning they had commit access to the live cvs repository. However, this did not mean they could commit fixes to the repository as one might to a BSD cvs repository. All changes went on a branch, and the only way a change could be merged onto HEAD was if it went through an internal Apple change control process. External committers were not able to attend these change control meetings, so they needed to get an Apple employee to sponsor the change. Once a change made it through the change control process, the change could be merged to HEAD, tagged, and submitted to the Apple build process, which usually meant your change would eventually make it into a Mac OS X/Darwin release. However, Darwin Developers could not submit to the Apple build process either. So, as a Darwin Developer, once your change made it onto a branch, that was about all you could do besides harass and Apple developer to take it the rest of the way.

Even with all these detriments, it was still possible for a determined individual to work with Apple developers and make meaningful contributions to the project. However, this was not to last. Something happened that caused Apple to get defensive and start removing some of the transparency: success. Apple started developing a developer base around Darwin that was fixing bugs and helping the product. They also got users interested and involved, following commits, bug reports, and mailing lists. People started to notice things, like their bugs were not being worked on or deemed unimportant, or just not getting the response they desired. People started abusing the system, mailing developers, managers, and executives directly because their pet bug/feature/etc. was not getting the attention it so clearly deserved. The easiest and fasted way to make this problem go away was to remove the nightly bug snapshots. This eased up the abusive mail received by executives, but it also made it difficult for the external developers to see what needed to be done, and how they can help out without duplicating effort or working on something that has already been deemed unimportant. However, the mailing lists and the cvs repository were still available, so people trudged on.

As time went on, and Mac OS X got closer to release, Apple decided they wanted to keep some thing secret. Some new features needed to be worked on, but couldn't be in the live cvs repository, or it wouldn't be a secret anymore. Some things leaked out, which caused no end of fuss, and gradually projects were removed from the live cvs repository. Eventually, so little was left in the live cvs repository and processes already needed to be in place to do periodic source drops, the live cvs repository was abandoned. For a while, the project floundered, trying to figure out how best to deal with the situation. Source drops continued to be made to an external cvs repository, but all agreed that made little sense. Eventually, Apple settled on the system that is currently in place, where .tar.gz files are placed on a web page.

Not only did access and availability diminish, but projects started to disappear altogether. In Darwin 1.0, source to everything was included. In Darwin 1.3, some drivers started to be included without source for ppc, but the Darwin/x86 variant still had all the source available. Over time, an increasing number of drivers and other projects stopped having their source available. For the most part, these were leaf node projects and not having the source didn't prevent people from continuing to be able to build things. Eventually, the closed source portions of Darwin encroached on other projects, and it became increasingly difficult to build Darwin.

During the transition to snapshotted source releases, another transition was happening. This was a transition away from Darwin source to Mac OS X source. This is a subtle but important difference. Darwin source could be reasonably expected to be consistent and be used to create a Darwin standalone os release. Mac OS X source was the source used to build Mac OS X, which could include dependencies on non-open source projects, making it difficult to impossible to build a Darwin release, or even to build these projects on a stock Mac OS X system. Darwin is clearly fading into the background now.

Despite all Apple's decreasing involvement with Darwin's Open Source, significant progress was made in one area: building individual projects. Darwinbuild was introduced during the 10.4 development cycle (when all mere mortals had was 10.3 source), and it was meant to be a relatively simple tool that allowed mortals to build Darwin projects as close the the way Apple does as possible. It even allowed developers to create patches to the Apple source, which aided in porting your changes across several Apple source drops.

Darwinbuild revived interest in Darwin again, at least in a few people, now that building the source did not take superhuman effort (or a team of full time individuals and a build farm). Problems still remained. Because the source drops occurred only when Apple made a binary release, and by the time bits hit the public, Apple developers were already hard at work on the next release, it was impossible to tell what bugs were already fixed, what features were being worked on, etc. Despite being able to build source, trying to fix bugs and make contributions back to Apple was and is a pointless task.

Even now, we are going through yet another cycle of losing access that we once had. With the release of Mac OS X for x86 processors, Apple has chosen to not release source to key components of the OS, such as the kernel and all drivers. This means Darwin/x86 is dead in the water, Darwin/ppc has many closed source components and is a deprecated architecture. One has to wonder why Apple even bothers to release non-GPL'd source at all, if it is unwilling to cooperate with external developers to increase their return on investment and accept external bug fixes and features. Even worse, one has to wonder why people would want to donate their time to such a fruitless and pointless cause.

Feb. 21 2006