The Proper Context for Apple and Open Source

There has been a great deal of confusion surrounding Apple and Open Source. Apple its self has been somewhat schitzophrenic in it's own open source directions. The most effective and productive view of Apple's open source efforts is that it is for development of and on Mac OS X. This sounds incredibly vague, simple, and obvious, but I will clarify.

Apple has been all over the map with it's open source efforts, from producing and releasing a standalone OS in the form of Darwin, to open source applications that are only relevant on Mac OS X, to standalone applications usable by the open source community as a whole. The success or failure of Apple open source efforts entirely revolves around how the open source efforts relates to the development of the commercial Mac OS X product. Apple is in the business of releasing products and making money. I make no value judgement here, it is simply a fact. Darwin OS is tangential to the Mac OS X product and is treated as such. Apple is not developing for on or with the Darwin standalone OS, they are developing Mac OS X. Similarly, Apple is not developing tools for general open source use, they are developing tools and applications for Mac OS X. Following this rule, it stands to reason that the open source efforts revolving around Mac OS X are Apple's most successful efforts, such as webkit.

The most satisfied consumers of Apple's open source efforts are people developing for Mac OS X. They use Apple's open source as documentation and example code to aid in the development of their own projects. In this regard, Apple's open source efforts are very useful. In addition to just access to the source, Apple's engineers are much more helpful and forthcoming when people are actively trying to use thier technology.

However, there are a group of traditional hackers who are not satisfied simply with development on a platform, they want to participate in development of the platform. This is (with limitations) entirely possible with today's level of interaction from Apple. Setting expectations appropriately is key to this kind of development. Here are some general guidelines:

If you modify your Mac OS X system, don't be surprised when Software Update or other installers overwrite your changes.
Do not assume Apple will integrate your changes. If you are developing your Mac OS X system, do it because you want to, not because you expect your changes to be integrated.
Be patient when reporting changes or bug fixes to Apple. Depending on when in the release cycle you reported your change, it can take 2 or more releases of Mac OS X to see your changes integrated (if at all). Never expect your changes to appear in a software update.
Don't be surprised if the area you were developing in was completely rewritten, deprecated, or removed when the next version of the product is released.

With those warnings, the best areas of Mac OS X to work on are middle areas. That is to say, above the kernel and below the GUI. This is for pragmatic reasons of source availability, but also because engineers at Apple that work on the "middle area" components are generally more involved in the open source community and more receptive to feedback. Additionally, you will be better off doing actual development, rather than simply working to update components. Updating components is rather routine for Apple and they are in a much better position to pick an opportune time to update components. Ideally, potential developers in this area would find a bug or a feature that they would really like to see addressed, and work on it. And as always, it is useful to report your change to Apple via an official bug report, but keep your expectations in line with the guidelines above. Remember that releasing a bug fix or feature on a mailing list or other public forum is no substitute for filing a bug with Apple.

The expectation guidelines above might scare off a few potential developers. They are very discouraging, although fairly realistic. There are a few things Apple could do to improve their open source efforts, both in terms of relations with developers, and maximizing their return on investment.

Stop releasing the Darwin standalone OS. Darwin has never been a compelling or useful OS on it's own, and the release of Darwin detracts from the more useful purpose of using the Apple sources for Mac OS X development. A case in point in CoreFoundation, and other Apple open source projects modified to build in a Darwin standalone environment as opposed to on Mac OS X.
Ensure that the sources released are compatible with Mac OS X. This is a change in focus for some Apple open source projects, where the goal has been to release what is necessary to build Darwin. The prime example here is CoreFoundation. As it stands now, it is not safe to use the CoreFoundation source on a Mac OS X system.
Be willing to honestly address the community in matters not relating to secret developments. For example, development of projects such as libtop, ps, or syslog are hardly secret and would be prime candidates for external developers to contribute much needed fixes. Perhaps even taking this as far as having a "hit list" wiki available to the public and updated by Apple, in lieu of Radar access.

I believe that by simply refocusing on the attainable goal of maximizing external development on and of Mac OS X, instead of continuing to confuse and frustrate the community with standalone OS releases, Apple's relationship with their development community will improve significantly. By not focusing on a Darwin release, resources can be freed up for other open source tasks, such as communication with the community, potentially in the form of shuttling non-critical information from outside Apple in, and vice versa. Apple engineers may become more receptive to the community that is actually interested in the technology they are developing, instead of how it relates to the irrelevant standalone Darwin OS.