Slashdot Mirror

I was pleasantly surprised to see KDE developpers rally to GNOME's cause, or at least, advocate the use of GNOME for those for whom it works, regardless of their own opinion. Both DEs are there to stay and the sooner people accept this, the sooner we can build a strong integration layer and move on toward world domination. (Which is why the GNOME people really should get rid of Ximian and its DE fundamentalists if they want to make any progress, by the way -- at least until Ximian gets out of their corporate-love funk and re-learn the OSS virtues of collaboration...)

If I'm right, Safari is not the only browser that passes Acid 2 Test.

Acid2 checks a bunch of relatively obscure cases that had remained unimplemented or incorrectly implemented in every major browser. The intent wasn't to determine a browser's level of CSS support, but to encourage browser vendors to fill in the gaps in their implementations.

At the time it was released, no browser passed it. Since then, Safari, beta versions of iCab, and CVS versions of Konqueror have passed. Opera's in-house development versions are getting very close -- they basically have one bug left. Opera was finalizing the 8.0 release when they developed the test, so they put all the Acid2 effort into 9.0 -- just as Firefox was basically frozen for 1.5, so all of Firefox's Acid2 work is going on in the trunk that will eventually become Firefox 2.0.

It's theoretically possible for one browser to pass Acid2 but actually implement less of CSS than another browser that does not, if the missing features don't impact the rendering of the Acid2 page. Just looking at W3C's CSS Test Suites should give you an idea of how complicated CSS compliance is.

Well, this klik developer thinks FUSE will aid in some significant way in the future.

http://www.kdedevelopers.org/node/1578

At least with Konqueror the standard identification never worked for me, posing as Mozilla worked until recently but doesn't now while setting the user agent to Safari didn't work then but does now.

More about that here (well more about GMail support but afaik it's the same problem)

> Its really sad that Windows with all its services and stuff uses 1/2 the RAM of KDE alone.

Does it? How do you know? Sorry, but this looks exactly like a yet another clueless post from somebody who doesn't even know how to actually measure memory usage on Linux (http://www.kdedevelopers.org/node/1445). Your claim lacks some important numbers, Windows version to start with (ok, XP is not exactly a number) or the memory usage numbers themselves.

Hey, pass her ("hot, blonde") the contact data of the FreeNX developers too, will you? See here:

FreeNX Project Members

These guys have achieved brilliant things. They deserve some female distraction. Especially pipitas, I think.

It'll be like a second Christmas!

Did you see the part about "pre-release versions working correctly?" As in, the release versions don't work, but future versions will work.

Not-yet-released-but-in-cvs Konqueror passes Acid2 according to this article.

Heck, it was even reported on /.!

... fix the vulnerabilities in Drupal. http://www.kdedevelopers.org/ was running Drupal and was hacked into.

Off-topic, but...
xorg now has support.
Still is rather buggy.
http://www.kdedevelopers.org/node/view/611
Googled for transset

[As Cies Breijs said]

My congratulations to all parties. Apple for beeing cooperative, and for giving back. To Zack Rusin http://www.kdedevelopers.org/blog/14 for sharing his opinion and reasoning, which openen up this issue.

If would be 'cool' if KDE-Konq and OSX-Safari use the same codebase for HTML-rendering and running JavaScripts. It would be 'cool' is KDE and Apple coders would work together on this.

Yet... if this will not be the case it already is a big help that both parties can view each others cvses/svns and bug databases.

I think once again Apple shows it really wants to play nice/fair with free/open-source movement.

Thanks for the good news :)

Wha? Dave Hyatt posted his announcement on April 27. Based on the comments to that entry, the patches were available around 11:00pm that night. Zack's blog entry is dated April 28, with a timestamp of 6:12pm (I don't know what the relative time zones are).

In any event, it looks like the patches were available a good 18 hours before "KDE team went public on what a mess the whole situation was." Unless you're referring to something else?

When Konqueror doesn't follow Safari's new feature within 4 hours, don't blame us. When Konqueror finally follows Safari's feature list, don't automatically praise Apple, either.

It's not like Apple is giving out some drop-in patch, but that's OK. That's their right. Sometimes we take their patch, but sometimes we write things from scratch. When we'll use Apple's code, we'll be slow because of the way they produce their patch, not because we're lazy.

Apple is OK for me, but please stop bashing our laziness while praising opensource-friendliness of Apple. That hurts.

You know it's not kosher to paint KDE's users as idiots.

Well, the word I used was naïve; the word Zack Rusin used was clueless.

However, perhaps I misspoke when I said KDE users - I should have said jackasses on Slashdot. :-)

"They do the very, very minimum required by LGPL."

"They made a conscious decision about not working with KDE developers. All I'm asking for is that all the clueless people stop talking about the cooperation between Safari/Konqueror developers and how great it is. There's absolutely nothing great about it. In fact "it" doesn't exist . Maybe for Apple - at the very least for their marketing people. Clear?"

• Here's a little theory of mine: users are more concerned with having a great UI and having apps that work together than raw speed. Open source desktops used to have the speed advantage, but not anymore. Can anyone honestly say that GNOME is faster than Windows XP's desktop these days? Same for KDE and MacOS X.

plz read, Carewolf on Safari - Submitted by carewolf on Fri, 04/08/2005 - 11:02. , 1st.

This is a bit like racing. And I think we need to look at the: 'Car' [hardware] - 'Driver' [Software] Package. Not just who's 'fastest'.

I mean, Apple has one powerfull-powerplant [hardware] they utilize - so no wonder the 'Driver' [software] is so fast!

While, "we" in the F/OSS-world utilize commoditiy hardware, as our/the developers pockets aren't that 'deep' ... - so no wonder the 'Driver' [software]' doesn't kick-ass all the time :-)

A Review I'd like to see, is where they take an Apple-PowerMac underclock it to match the same performance as the 'commodity hardware' .. and then compare the 'Drivers' [Software's] against each other!

>See, people kind of listen to you when you are successful as opposed to when you sit and whine because your take on things just doesn't seem to be taking off

You seem to also have to be successfull to make people actually read the stuff that the KDE developers write about the situation.

You see whining about your take on things just doesn't seem to be taking off

>See, people kind of listen to you when you are successful as opposed to when you sit and whine because your take on things just doesn't seem to be taking off

You seem to also have to be successfull to make people actually read the stuff that the KDE developers write about the situation.

You see whining about your take on things just doesn't seem to be taking off

>See, people kind of listen to you when you are successful as opposed to when you sit and whine because your take on things just doesn't seem to be taking off

You seem to also have to be successfull to make people actually read the stuff that the KDE developers write about the situation.

You see whining about your take on things just doesn't seem to be taking off

I agree that this Firefox guy should keep to himself with that kind of statement...

But I really think that the guys from KDE, contrary to most flamewar lovers on slashdot, do actually lead a hopefully fruitfull discussion.

Nowhere in any of the linked material does it mention that the beef is actually with users. If so, you should be complaining about the shitty journalism, not me who happens to be responding to it.

I don't know how many people read the ORIGINAL kdedevelopers.org blog entries on the subject, but one of the specific complaints is:

[Apple] should not be putting Cocoa/Object C code in patches to KHTML. Writing an abstraction layer wouldn?t be that hard and would be beneficial to everyone (including Apple) in the end.

Doesn't sound like such a generous act of corporate citizenship to me.

(Posted with Konqueror 3.1.4)

• Notice how there isn?t a vs in the title?

  Hyatt and Maciej joined us on IRC yesterday, and we had some really good discussions. I might as well also admit that Maciejs comment was true (but out of context). Please notice that that implies we are discussing solutions and a common future. The idea of a common source tree is pretty much abandoned as we have very different goals and requirements, but we are discussing improved cooperation. With Apple just having released Tiger and us preparing for KDE4 we have a unique opportunity for bringing our source trees closer again.

  Since Apple is being a nice guy for the time being, I will let them announce how things will improve once we have a solution, but please, no more ?vs.? stories for the time being, we are working on solving it.

• I just wish to weigh in on debacle to clear up some mistakes. First of all I would like to say I agree with Zack. The annoying part is not that Apple don?t cooperate as much as they could. They are actually helpfull in answering questions and _tries_ at least to separate OS X specific features in the code (allthough they fail miserably at it). No, our problem are users who think Apple does more and underestimate the effort it takes for us to implement patches from WebCore. We are doing this for free and for fun, all we really want is appreciation for our effort.

• Notice how there isn?t a vs in the title?

  Hyatt and Maciej joined us on IRC yesterday, and we had some really good discussions. I might as well also admit that Maciejs comment was true (but out of context). Please notice that that implies we are discussing solutions and a common future. The idea of a common source tree is pretty much abandoned as we have very different goals and requirements, but we are discussing improved cooperation. With Apple just having released Tiger and us preparing for KDE4 we have a unique opportunity for bringing our source trees closer again.

  Since Apple is being a nice guy for the time being, I will let them announce how things will improve once we have a solution, but please, no more ?vs.? stories for the time being, we are working on solving it.

• I just wish to weigh in on debacle to clear up some mistakes. First of all I would like to say I agree with Zack. The annoying part is not that Apple don?t cooperate as much as they could. They are actually helpfull in answering questions and _tries_ at least to separate OS X specific features in the code (allthough they fail miserably at it). No, our problem are users who think Apple does more and underestimate the effort it takes for us to implement patches from WebCore. We are doing this for free and for fun, all we really want is appreciation for our effort.

Apple went with KHTML instead of Mozilla. Instead of gratitude, the KDE devs are angry that Apple isn't tailoring their patches for them? The fact that Safari uses KHTML has done more for web page compability with Konqueror than years of development and advocacy could ever have done. Just look at the proportion of top-tier web designers on Macs.

The KDE developers were complaining about people who say they should be grateful for Safari. Perhaps you need to look more closely at Zack Rusin's blog on the topic.

Well, maybe before everyone starts criticising KDE developers and Apple and everything, they should get a little more information on what is being done to solve the problem: http://www.kdedevelopers.org/node/view/1046

As the guy suggests, I would advise everyone (especially developers of other projects who probably aren't that well informed) to keep quiet with the "vs" stories for a while and see what comes out of this.

I love Mozilla, but this is nonsense. Obviously he did not read
this.
Let Goodger get back to selling the world on Firefox or whatever it is that he does and leave KHTML en Webcore to their respective developers.

> You're talking out both sides of your mouth now. Forks are absolutely needed in OSS. Never forget this.

Did I say otherwise ? I don't remember doing that.

> [a hostile fork is] not what Apple has done. Rather, Apple has done what I would call a 'closed' fork.

A rose by any other name is still a rose. I stand by my opinion : a fork that doesn't give a chance to the original developers to keep in sync is hostile, by definition.

> they forked the code and went their own way with it. As a result, their changes become more meaningless every day as the two projects go off in different directions. This is what the grandparent poster was referring to when comparing Safari/KHTML to XFree86/X.org

The *BIG* difference being that the XFree86 developers can look at the X.Org CVS and integrate X.Org enhancements without the need to reverse-engineer a huge, unwieldy patch. If a commit in the CVS says "fixes bugzilla #x", they can go to the Bugzilla and see what that bug was about. In fact, the Debian X Strike Force managed to pull bits of X.Org in their modified XFree86 for a while. They'd most probably not been able to do so if X.Org had just periodically released big chunks of patches without change history. Apple's fork is *way* more hostile than X.Org's !

> Obviously Apple's code isn't going to mean a lot to you.

Why would that be ? A patch for a rendering bug in the kHTML code would definitely be relevant for the kHTML developers. Of course, there are parts that are meaningless for them (the KWQ code, for instance) but that's not what they are after.

> the KHTML devs don't give two flying shits about the Apple changes

Are you sure ? Zack Rusin, at least, seems to give a little more than "two flying shits" in his last post...

> can you really expect Apple to attempt to keep their code as synched as possible?

I was under the impression that, rather than getting Apple to keep in sync, the goal was more to allow the kHTML devs to be able to keep in sync with Apple.

> the problem is that people [...] are going around blowing the "Yay, Apple loves Open Source!" horn, which is both true and false.

Well, sure it is. A corporation the size of Apple will obviously have different approaches according to the department in charge. The problem here is that the Safari dept. is not that cooperative.

> Apple wants to use OSS code, but they want to have the freedom to go their own way with the product. That's why it's called a FORK.

Absolutely. They're entitled to act like jerks. But if they choose to do so, people are surely entitled to say that they act like jerks, too.

> If you don't like it, [...] use the GPL, that's why it exists.

The GPL wouldn't have helped a bit, there. There is nothing in the GPL forcing you to give public CVS access or clean patches, just the modified source, exactly like the LGPL. This is not a license violation problem ; it's a lack-of-niceness (or even a lack-of-decency) problem.

> What really pisses me off about your post, however, is your lovely little piece of "o look at me i'm going to go against the grain on slashdot, i'm so much BETTER than you fanboys."

That's fine. What pissed *me* off was the whole lot of posts rudely dismissing the KDE guys' concerns, and basically likening them to a bunch of whiners, an attitude that seems to be pervasive everytime there is a story about a conflict involving Apple Corp. or Google, Inc. (the best bit of nonsense being the guys that always suggest Google purges people that oppose them from their engine. It never fails to make me laugh). If my bit of sarcasm offended you, then please accept my apologies, next time I'll put up a disclaimer.

Shit it's hard to handle appropriate levels of contextual quoting in slashdot-HTML - at least for this long a post *wry grin*.

Most commercial companies have to deal with customer information privately and that means restricting access to versioning systems, bug databases, trouble tickets, and code comments.

And that's fine - Apple is well within their rights to do that. But doing that makes it a hell of a lot harder to consider Webcore a genuine open source project.

WebCore is as open as any open source project, [...]

As open as a project like KDE, which has a completely open source control system, a wide array of open and searchable development mailing lists, and an open bugtracking system? No, I though not :-). See below.

Bullshit. WebCore is an open source web engine and there are even several new open source browsers based upon it [ ... ]

You misunderstand my point. I didn't say that Webcore wasn't under an open source license, nor did I suggest that Apple was violating the license in any way.

What I did say was that Apple wasn't running Webcore as an open-source project. A serious OS project should first and foremost have the source developed in an open and freely accessible source control system (though this is not an absolute - many less active OS projects can achieve much the same result with infrequent tarball releases, mainly because updates to the project are infrequent). Less important, but also good, are openly accessible development mailing lists (though again there's some degree of variation here - some projects have a closed "core team" list - but the vast majority keep all lists open). An open and freely accessible bugtracker is also a big plus (though again, there's a fair amount of scope for restricting access to important security-related bugs, as does the Mozilla project with Bugzilla).

Regarding the different priorities between Webcore/KHTML:

Actually I think this is the major problem.

Well, it certainly seems to be a big part of the technical problem :).

That's funny I heard the acid test patches were broken up into small chunks and had comments specifically for the KDE team telling them what applied to what as far as the codebase was still the same.

As far as I'd heard, that was a case of too little, too late and I seem to recall another KDE dev suggesting that Hyatt only did it because he (the KDE dev) dared him to (as they'd been asking for lightweight atomic patches for ages with no response). I hope that's wrong and Hyatt is genuinely trying to help the KHTML project - it certainly looks as though he is, going by his blog.

Re: a comment I made about the Apple devs not being willing to answer question or explain changes:

Got any source to back that up?

Actually, no. Dammit. I thought I'd seen a couple of references on the KDE dev blogs regarding the Apple Webcore devs being "unresponsive" to requests for information, but I can't find those references now - I might even have misremembered them. I hereby withdraw that comment.

Well you certainly are opinionated, but I don't think you're as informed as you seem to imply. WebCore is a thriving open source project with numerous new browsers for both OS X and Linux based upon it.

You're dead right on the opinionated count :). And I'm sorry, I didn't mean to imply I was that well informed :).

My main objection to the "Webcore is a genuine open source project" is covered above - the lack of an openly accessible source control server is a bit of a deal-bre

It's unnecessary for me to do this. Zack Rusin has done it already in his blog here,

http://www.kdedevelopers.org/blog/14

Far be it from me to tell Apple what they need to do when a lead developer of KHTML is already doing it.

It's damn fast for KDE compile as someone tested.

Yeah, I went through the comments on Dave Hyatt's blog and found this link in the comments section (the same link you give above), and I was pretty shocked. Like most folks, I thought that KHTML was benefiting from Apple's contributions. However, after reading the critique by Zack Rusin (one of the KHTML developers), I took a closer look at some of the patches that Dave Hyatt posted links to on his blog.

While many of the patches were simple logic changes, a few of them had OS X specific code in them which makes them non portable. Hyatt's follow-up comments indicate that he tried to hide many of the Mac-isms behind an abstraction layer so that they could port cleanly to other platforms, but a cursory glance at the patches shows that he didn't hide everything.

So while this is a great win for Apple and for Mac OS X, it's not the boon to KHTML that many thought it would be.

Personally, I'm disappointed that the Safari team would put Mac-specific code into the KHTML engine, making some of their patches impossible to incorporate back into the KHTML baseline. This is the kind of thing I would expect from a novice programmer who's only ever coded for, say, Windows.

(Just a side note to the poster I'm responding to: Most folks who read your comment probably didn't realize the significance of it because they didn't follow the link. A brief summary of what the link is pointing to would have been really useful.)

http://www.kdedevelopers.org/node/view/1001

From your previous sibling post:
http://www.kdedevelopers.org/node/view/1001

http://www.kdedevelopers.org/node/view/1001

Mayhaps you don't have a clear picture...

Though the GP's link is a bit old (an email from July) there is still an issue with Apple's patches.

Look here, a blog entry from today by that same KHTML hacker

Apple's contributions back to KHTML are not in any way useful. They contain features that use the OSX API, and patches that rely on code in the features. They don't send incremental patches, they send gigantic tarballs that have to be reviewed to make sure they won't conflict with vanilla KHTML.

I like Apple (I'm typing this from my ibook), but I hope they start working with the KHTML guys instead of over their heads.

Bill

That most probably will never happen. You can read Zack Rusin's rant about it.

Well, that points out that "true" open source development is not only about licenses but about the will to cooperate too.

From his latest blog entry:

"Do you have any idea how hard it is to be merging between two totally different trees when one of them doesn't have any history? That's the situation KDE is in. We created the khtml-cvs list for Apple, they got CVS accounts for KDE CVS. What did we get? We get periodical code bombs in the form of them releasing WebCore. Many of us wanted to even sign NDA's with Apple to at least get access to the history of their internal vcs and be able to be merging the changes incrementally, the way they can right now. Nothing came out of it. They do the very, very minimum required by LGPL."

Go read the whole post. Very informative, and kind of sad.

From his latest blog entry: "Do you have any idea how hard it is to be merging between two totally different trees when one of them doesn't have any history? That's the situation KDE is in. We created the khtml-cvs list for Apple, they got CVS accounts for KDE CVS. What did we get? We get periodical code bombs in the form of them releasing WebCore. Many of us wanted to even sign NDA's with Apple to at least get access to the history of their internal vcs and be able to be merging the changes incrementally, the way they can right now. Nothing came out of it. They do the very, very minimum required by LGPL." Go read the whole post. Very informative, and kind of sad.

LGPLed actually, but Apple is usually pretty good about contributing stuff back.

Umm, not quite. Pointing towards a link made by someone ealier here:

We created the khtml-cvs list for Apple, they got CVS accounts for KDE CVS. What did we get? We get periodical code bombs in the form of them releasing WebCore. Many of us wanted to even sign NDA's with Apple to at least get access to the history of their internal vcs and be able to be merging the changes incrementally, the way they can right now. Nothing came out of it. They do the very, very minimum required by LGPL.

And you know what? That's their right. They made a conscious decision about not working with KDE developers. All I'm asking for is that all the clueless people stop talking about the cooperation between Safari/Konqueror developers and how great it is. There's absolutely nothing great about it. In fact "it" doesn't exist. Maybe for Apple - at the very least for their marketing people. Clear?

Don't believe everything Steve Jobs tells you, so to speak.

Also, that thread was from almost a year ago - when Hyatt and the khtml devs where still relatively new to this whole "working together" thing. It's interesting that you didn't have a newer email to link to.

How about a blog from today?

Really?

Apple feeds their improvements back to KHTML after the Safari version they appear in is public.

Although it doesn't seem to be very useful.

> Will the patches appear in Konqueror (KHTML)?

Zack Rusin just blogged about this.

Why does everyone keep saying this only on Slashdot? At least Google doesn't find anything when I do, "KHTML Apple mangle"

If I look for "KHTML Apple contributions" I at least find this, which specifically says, "We still have not finished merging in the fist batch of patches.

No this is not because of incompitance on ANYONES part, but because of the lack of time and resources. We already broke BC in KJS just to support apples changes because they where that awesome. Its just these things take time. So if you anxious, get out your text editor and lend a hand!"

Searching for "KHTML Apple patches" gets you this, which says, "pple also tends to submit their changes in large patches that incorporate a great number of changes, in some cases leaving code to do with future feature additions barely documented, making it difficult for the KDE developers to sort through and incorporate the changes. However the KDE project has managed to incorporate a number of changes that have added features and improved KHTML's rendering speed."

So Apple isn't exactly making it easy for KHTML folk, but they aren't, as you say, "useless and cannot be put back into the main project." Rather, "the KDE project has managed to incorporate a number of changes that have added features and improved KHTML's rendering speed."

Unless you are a KDE developer? I know I'm not, but I've never heard these allegations except in Slashdot.

Hard drive mp3 players existed for a year before the iPod and they consisted of two models:

The Creative Nomad, 14oz, 5"x5"x1.5"
The PJB100, 10oz, 6"x4"x1"

Apple released the iPod and made it a consumer object, rather than a geek object. Apple changed the entire market! Before Apple they were:
Large (bigger than a paperback. Now all of them, LIKE the iPod, are smaller than a deck of cards)
Heavy (at 10oz or more. Now all of them weigh less than 6oz)
Slow (using USB 1. Now all of them, just like the iPod, use USB2 or FireWire)

They were good for cars, good for work, good for train trips, and good for airplanes, before Apple got a hold of them. After Apple they became good for walking, roller blading (yes I have rollerbladed with iPods), working out at the gym, anywhere.

It was like the difference between a desktop and a laptop, in mobility.

The same with music stores. Before the iTMS, there were NONE that let you burn to CD. NONE that let you upload to an mp3 player. NONE that let you listen on multiple computers. NONE that let you back the music up. You say, "In the works", and I say, "Quickly saw what Apple did and tried to match them."

The only other player besides Apple who has made any money off Open Source would be... IBM. Red Hat hardly makes money, GNU and Apache aren't profit centers.

Here's the initial announcement and response about Safari's use of KHTML, with positive response from developers.

This suggests developers haven't been able to keep up with Apple's changes, which makes sense; a handful of developers working full time on anything can outstrip hundreds of developers working part time over weekends and evenings.

As for gcc, the idea is to search gcc-patches and look for apple.com addresses. Searching Google shows over 6k hits, though I'm sure some of them are duplicates. Some Apple devs maintain special branches (for example, in implementing ObjC specific features) while others contribute fixes, or add Altivec/VMX specific patches.

Where do you get your info that Apple ISN'T contributing?

This has got to be a troll, since you're cheering about Microsoft's open source contributions, but I'll bite.

First, Apple cannot possibly contribute to all the open source software projects that ship with their OS. Neither does Sun, or Red Hat, or IBM, or anyone else. It's simply not possible. Everyone takes more than they give. It's like asking a Linux user to contribute to every open source project they use. They can't. But that's part of the beauty of open source: there is a huge amount of high quality code out there with healthy developer communities that a software vendor (and end user) can put to good use without having to vet every single line of code themselves. And when all of those vendors each give back to a few of the projects they use, it feeds back into the health of the entire open source community. So, every company can't help every project, but every project can help every company (and user). That's a good thing, the way I see it.

And, Apple does give back. Particularly to GCC, FreeBSD userland, KHTML, X.org, Postfix, and others. And they always publish source for any modifications according to the appropriate license. I'm too lazy to go look up specifics for all of those, but there's a quick writeup regarding KHTML at www.kdedevelopers.org. Examples of the others shouldn't be too hard to find. But, you're not likely to see much front-page press about it. "Vendor X gives some code back to project Y" won't capture people's attention like "Vendor X stole code from project Y and is violating the license". You can scan the Slashdot headlines for proof of that. :)

I cannot personally think of any mainstream Apple software that Apple has made OSS.

Well, there is Quicktime Streaming Server. That should count for something. There's also OpenPlay, and Rendezvous. Anyway, there's a list on Apple's site, go take a look. It's not Apple's fault if none of the projects they have put out there are anything that you want to use.

but what has Apple really given of their own creation?

QSS, as just mentioned. Anyway, you can't make any money by just giving everything away. Ask Red Hat. Anyway, every vendor has to keep certain things for themselves to differentiate their product or there would be no reason to buy their specific product. That holds true for any vendor using open source code, be it Sun, IBM, SGI, Apple, or anyone else.

What about Quartz, Aqua, iTMS, iTunes, "Fairplay", Sorensen?

Quartz: I highly suspect there may be issues with IP from the display technology vendors. ATI and NVidia are stingy with their IP, which is why there are no real open source drivers for their display cards for any OS.

Aqua: Apple's UI is their main point of product differentiation, besides the custom hardware. Giving away Aqua would be like giving the hardware away.

iTunes/iTMS/Fairplay: They can't release the source to these because it would compromise the authentication/DRM scheme that allows them to sell RIAA music in the first place. But even so, who cares? DRM sucks anyway and I won't buy DRM encumbered music from anyone for any cost. And, if you want to use iTunes for library management, there's Crossover iTunes.

Sorenson: Not Apple's IP to open source. Go talk to Sorenson.

Pay no attention to leonscape . He's probably still bitter that his website got infected by the Santy worm. Classy.