Slashdot Mirror
Safari vs. KHTML
Johnny Mnemonic writes "CNET has a story that describes the divergence between the code base of Safari and KHTML. Although there were high hopes that Apple would contribute significantly to the OSS project, that optimism has all but disappeared. Is an unrealized danger of OSS that others may take your project in a direction you didn't intend? Can OSS code and goals harmonize with the goals and needs of corporation designed code? Is it that Apple mismanaged the relationship, or that the KHTML guys expected too much? Interesting warning for other OSS-corporate marriages." We've previously reported on the frustration in the OSS community on this issue.
Afaik the relationship between apple and freebsd is fine, and they use eachothers' patches etc. The problem seems to be that apple wanted to develop the browser in another direction than kde, and the communication stopped as they didnt use eachothers patches. As apple are having paid developers working on it, they should develop it their way and kde should maybe look at their methods to see if they are able to work in that way. If not, though luck.. I cant see that apple is the bad guy here.
We've previously reported on the frustration in the OSS community on this issue.
Atleast you're being honest.
As long as they're abiding by the terms of the license, does Apple, any corporation, or any entity for that matter, have any obligation to contribute anything back to the project? Who gets to decide when someone is contributing "enough"?
Additionally Apple posts all of its open source code; here's the page for WebCore, which states:
WebCore is a framework for Mac OS X that takes the cross-platform KHTML library (part of the KDE project) and combines it with an adapter library specific to WebCore called KWQ that makes it work with Mac OS X technologies. KHTML is written in C++ and KWQ is written in Objective C++, but WebCore presents an Objective C programming interface. WebCore requires the JavaScriptCore framework.
The current version of WebCore is based on the KHTML library from KDE 3.0.2. Changes that are specific to WebCore are marked with #ifAPPLE_CHANGES. Other changes to improve performance and web page compatibility are intended for integration into future versions of the KHTML library.
Sounds like a case of sour grapes to me. I'm sure the level of cooperation and collaboration that the KDE/KHTML/Konqueror folks had hoped for wasn't there, if only because Apple keeps everything secret before its release (including everything related to Safari 2.0 in Tiger). Another example of a corporate need butting heads with a contrary OSS philosophy. And I'm sure Apple's main priority is not developing an infrastructure to cohesively and voluminously contribute changes back to projects. It's more like, "Ok, here's our stuff..."...it's all there for anyone to see.
- Suse
- RedHat
- *BSD
- Knoppix
- Mandrake
And there are definitely more that I haven't included. If Safari diverges form KHTML, it's fine with me.In the article, Apple engineer Maciej Stachowiak said,
"One thing you may want to consider eventually is back-porting (WebCore) to work on top of (KDE)... We'd be open to making our tree multi-platform."
I wonder if that means they are looking to port Safari to Windows. It would give Windows users another taste of the Mac, and I for one would use it.
It's not unrealized, lots of projects have forked before. I think anybody who puts their code under a license that allows forking will realize that it can happen.
Can OSS code and goals harmonize with the goals and needs of corporation designed code?
Of course it can, this happens every day. Look at the kernel, GCC, Wine, etc.
Is it that Apple mismanaged the relationship, or that the KHTML guys expected too much?
I don't think expecting documented patches or a shared bug tracker is asking too much - this is the pretty much the minimal level of co-operation most projects would expect from a corporate good citizen. Some companies go even further than that, and hire some of the core developers, sponsor conferences, provide hosting facilities etc. There are plenty of examples in the Linux community of companies doing that.
So did Apple mismanage the relationship? Arguably there is no relationship. They certainly mismanaged expectations - if they'd come straight out and the beginning and said "we're not going to co-operate" a lot of frustration would have been avoided. That would have harmed their (mostly imaginary) pro-open source image though.
I doubt there's some kind of Evil Plan to screw over KDE here, it's more likely that Apple don't care or want to help the open source community, it's just a convenient place to take code from (go see how much FreeBSD has got back from them, for instance). Open source and Linux specifically are primary competitors and they'd be foolish to help the community more than they have to. After all, they're in the business of selling proprietary operating systems.
Lars T.
To the guy who modded me down from perfect to terrible Karma - Apple haters still suck
Obviously Apple is not sharing there code! Slashdot looks great in Safari!
Dashboard Widgets
How is this different from any other OSS project? Two groups see the project going in two different directions and it forks. Granted, the Apple side on this one may not be as open as the KHTML people want, but in all honesty, I'm willing to bet that Apple has a much better code base than KDE at this point. The fact that Apple is suggesting a KDE backport of WebCore is pretty amazing. How many corporations do we see telling an OSS group, "Why don't you just take our code and use it for your project whole-hog"? My guess is not many.
Per Square Mile, a blog about density
Besides, last I checked, the KHTML folks don't have a beef with Apple. They do have a beef with the fanbois who can't seem to grasp the fact that Apple using KHTML's Open Source code does not immediately mean that they're best buddies.
All it means is that Apple is using Open Source code. Period. Apple isn't violating anybody's trust.
Obliteracy: Words with explosions
WebCore-413
And here's everything from 10.4, posted on the same day 10.4 was released. They even posted full binary PowerPC and x86 installers for Darwin corresponding to Tiger that same day.
Its probably best to think of Apple's WebCore as a fork of KHTML; they are no longer one and the same. Apple has already changed WebCore enough that backporting changes to KHTML is very non-trivial. As usual, they are starved for developers, especially when the task is simply porting someone else's code, rather than solving problems for yourself. Many devs would much rather do the latter, even if "results" come more slowly.
This stuff is just stupid. Apple has done absolutely nothing illegal; arguably they've done nothing inappropriate. KDE and KHTML are not in any way any less well-off, and if this story accurately reflects the attitude of the primary KHTML developers, honestly, they're being jackasses.
What all this demonstrates is why using free code (especially GPL/LGPL code) is much more of a minefield than a reading of the license would suggest. You can comply to every last detail, and it doesn't do you any good against the negative publicity when someone decides you "owe something to the community".
What I'm listening to now on Pandora...
Is an unrealized danger of OSS that others may take your project in a direction you didn't intend?
This is not a danger, it's simply a attribute of OSS. Do you really think Linus sat down to write the kernel and ever considered it'd be used on millions of computers worldwide for mission critical systems? When you release your code Open Source, your basically saying to the world "do with it as you please". Some license clauses may prevent certain uses (i.e. many OSS SMTP Servers have a clause that says if you use this software for Spam, you're in violation of the license). But as a OSS Developer I can't say that only Americans can use my code, or prevent those of other religions from using it to benefit their religion. And I certainly can't prevent some company from "leeching" by profiting from my work without giving back equally to the OSS community. That's life and that's OSS. Most companies however realize that as a whole, you get back what you put into something.
Apple has followed the obligation of the license.
:)
It's just a fork. Forks happen. Move along. If KDE guys think KHTML sucks compared to WebCore/Safari, they are free to fork THAT and start from there (backporting it to KDE). The source is open. Whine less, code more
If you didn't realize that's possible, you're just being stupid. If they're going in a direction you don't intend, then by all means continue in the direction you DO intend and don't worry about it. Would it be nice if Apple maintained a set of OSX specific patches and did as much as possible in the upstream project? Yes. Do they have to? No. Will it bite them in the future? Perhaps. The farther they diverge, the harder it will be to bring changes the other direction as well.
Duh. Of course. Do I really need to provide a list? Can't anybody here on /. think for half a second and come up with one or two OSS projects sponsored by corporations where the code and goals are "harmonized" as the questioner puts it?
Yeah, I'd like to hear about one or two projects like that. I'm not aware of any.
I don't respond to AC's.
This is nothing but a childish spat between 2 diffrent groups of developers.
Apple published the patches, and changes and KHTML cries about them having to much OSX specific code in them? Thats just crap..
Apple is acting in good faith, they are basically asking Apple to make sure all patches are 100% compatible with the current code base.
The KHTML team might as well just ask Apple to take over the project in full.
Open Source does not mean "Anything you do must conform and work with our project or your not doing it right"
Open Source is "If you make changes please give back to the community with the understanding that your changes might not be compatible with ours, Your code changes may not be what we want, but we can't complain about that"
Personal Website
Is an unrealized danger of OSS that others may take your project in a direction you didn't intend?
Isn't that point of OSS, hoping that someone will take interest in your project and do something with it you couldn't do yourself?
And what's dangerous about that?
Is an unrealized danger of OSS that others may take your project in a direction you didn't intend?
Oh come on, is this really a "danger"? Nothing in any open source license says that you keep the right to direction of whatever your code ends up as.
This is like the "danger" that your source code can be "hijacked" in commercial applications if you use the BSD license.
KHTML is not objectively any worse off because of this... Apple isn't hurting them, Apple isn't taking anything away from them, their project is not imperiled in any way. It may make them feel bad that their source is out there with improvements and it's not as easy for them to merge them back into KHTML as they would like. It's quite a mental exercise to try to think of a rational justification for that feeling without becoming extremely vague (try it), one which no open source license could ever protect them.
To borrow a phrase from ABC News' mustachioed libertarian: Gimme a break.
I think Apple made a decision that it needed to switch cores and at that moment has every right to do so and never look back. The fact that they are putting any effort into KHTML at all should be looked at as a mere bonus for the KTHML developers at this point. Apple never claimed to be the white night funding the KHTML project or that they would be the dominant developer for the future. This is not an example of IBM taking over a project. I think some KHTML guys read way too much into this relationship. It was pretty clear from the start that they were being used (but the nature of their license allows for this). It was great that they showed trust and attempted to built a relationship, but they should not have become in anyway dependent. I'm not saying this is the case, but the bitterness of their response seems to suggst this sort of dependence.
Could Jesus microwave a burrito so hot that he himself cou
The story is blowing up something that should not be. Apple has been contributing code back to the KHTML team. The team has difficulty integrating it due to the large differences and lack of man power. Apple is simply suggesting that the KHTML team work with Safari to have one code base, which is a good idea. while I am not wild about the KHTML losing control of things, Apple has a full time group working on the base. So why not do the firefox/mozilla thing and move to where the action is. Besides, if KHTML moves to working closer with apple, it will produce a third major code base, behind MSIE and Mozilla. Basically, 2 out of the 3 will be in the *nix world. In addition, the 2 will follow the standards closer, which will lead to more developers following standards.
I prefer the "u" in honour as it seems to be missing these days.
"One thing you may want to consider eventually is back-porting (WebCore) to work on top of (KDE), and merging your changes into that," Apple engineer Maciej Stachowiak wrote in an e-mail dated May 5. "I think the Apple trees have seen a lot more change since the two trees diverged, although both have useful changes. We'd be open to making our tree multi-platform."
The suggestion, which KHTML developers said they were unlikely to accept,
So Apple is open to making the tree cross platform, and presumeably to them back porting web core (which is nessesary to implement some of the things Apple has done since) and KHTML doesn't want to.
So by choice KHTML has already limited the changes they can use.
"In open source, everything's supposed to be done the right way, but sometimes the less correct way is faster," Rusin said. "In fixing one problem, they were breaking a whole bunch of other things. Apple developers were focused on fixing bugs in such a way that we could not merge them back into KHTML. Those fixes were never an option for us."
Ignoring for a moment the fact that OSS is not done the "right way" many times, Apple has an obligation to turn out code and to do it fast. They have obligations to their customers. The fact that KHTML wants to take their sweet time and Apple wants to get the patches done fast and out the door shows where the divergence is. Apple can't afford to take the open source approach of spending 5 years in beta before releasing the next version.
Once again a choice by KHTML. The patches are there, but they choose to do the patches their way, thus eliminating Apple patches.
KDE volunteers said they suddenly found themselves dealing with bug reports Apple deemed too sensitive to share, new requirements for auditing code before releasing it, and demands that developers sign nondisclosure agreements before looking at some Apple code.
So you mean once KHTML devs wanted access to code that wasn't part of KHTML, they had to play by Apple's rules? Say it isn't so! Apple plays by their rules for their code, but KHTML doesn't want to play by Apple's rules for Apple code. Again, choices by KHTML to limit their own options.
"As long as they needed us, they used us, but when they gained enough knowledge they had no reason to keep sending us reviews and patches," Rusin said. "At a certain point they decided it was a waste of time for them, and at that point the communication just stopped...We had hopes that they would pour resources into KHTML. But that never happened."
No, it did happen, but they're pouring resources in to the ways that allow them to serve their customers best too, and that means leveraging OS X technologies. KHTML has chosen to be just as uncooperative as Apple.
T Money
World Domination with a plastic spoon since 1984
you can't put donuts on the table in the break room and then complain when someone eats them.
Complaining about it shows a great lack of grace.
Apple hasn't done anything wrong. This is exactly the way OSS is set up to work. If someone made some software and you want to change it, you are free to do so. As long as you publish the changes. There is no rule you have to do it in a way that makes the original author happy, you aren't required to follow their vision. You are free from all that. If the original author likes what you've done, they should be able to take your work and merge it back in.
It's nice when everyone cooperates with each other, and keeps everything syncronized, but all that is frosting on the cake.
First off, I do KDE work, not Apple.
KHTML is under LGPL. Apple is doing what they are required. In addition, they have offered to move their code base to be multi-pltform. In the end, I think that the KHTML team will move towards this. It will allow full time developers on an import piece of work.
The article is doing a disservice.
I prefer the "u" in honour as it seems to be missing these days.
How many times have you filed a RFE on an OSS project and gotten this back? "If you don't like how that works, feel free to submit a patch".
Okay, if you don't like how Apple provides its patches back to the KHTML guys, please feel free to write a tool that converts their patches into the form you prefer.
#DeleteChrome
One of the things you learn about Apple as you work with them is that secrecy is paramount. Among other things, that means that NOBODY gets access to their bug database. Developers have been clamoring for a more-open database for years. KDE's not getting special treatment, that's how ALL of Apple works. Love it or leave it.
...by getting everybody on the same source control software.
AFAIK, KHTML uses CVS, and Apple internally uses Perforce.
Nothing constructive can be done until everything is on the same platform.
Apple, offer to buy licenses of your source control software for the KHTML core. Even if they still spurn you, it will appear to the rest of us that you at least tried. You will look more and more of a villan until you make some effort at a reconciliation.
p.s. The KHTML team will need to be conversant with OSX to the point that they can remove GUI calls to it and replace them with QT. If this is a current problem, then some books might be in order.
Dave Hyatt, one of the lead developers of Safari, has solicited comments and suggestions on his blog about how to better improve coordination between Apple's Safari group and the KDE Konqueror. team. Corporate support from Apple will have to follow, of course. I am sure that they are the main reason this coordination has not occured by now.
This definitely isn't a GPL violation, and doesn't even violate the spirit of Free/Open Source Software. The Apple developers are making their resulting branch of the code available in compliance with the KDE license. They're even trying to work to contribute their changes back to KHTML. Even if the patches don't apply cleanly, the KHTML developers are more than free to look at Apple's changes and add them by hand. Apple is even offering to give back their entire branch, to make it the new official KHTML, since their branch has advanced faster.
This really seems to be a case of the Apple guys offering their changes (or at the very least, making them available), and the KDE guys not being interested in them, or unable to use them for various reasons. It's really hard to blame Apple for that.
Software sucks. Open Source sucks less.
It's not Apple's fault the KDE development community doesn't have a lot of use for the code that makes WebCore.
This is the nature of OSS. Software continues to evolve and fork.
KHTML developers who can see the big picture beyond their own egos should be ecstatic that somebody has applied their effective, standards-compliant codebase to a commercially viable, successful product that will help bring tighter standards adherence to html / web authors.
It would certainly be a lot more sportsmanlike than "boo-hoo I can only use 10% of Apple's code".
Suck it up. You develop open source so that people can modify it for their own needs, provided they share their code with you.
I suppose the typical GPL liscence states that you need to share your changes or otherwise make them available.
But in practice, I dont think there is much stopping any given company from using an open code base to use a more or less closed product. The BSD liscence specifically permits this.
Being the sort that does not care much one way or the other about this topic, is Apple doing anything that the liscence in question prohibits?
If not, then its permitted, and if its permitted, no use complaining. If your going to have a code base that open, then you should not be shocked when someone uses that liscence to their own advantage.
END COMMUNICATION
It seems to me that there's nothing wrong with how either Apple or OSS/KDE/KHTML have gone in this project. While there were high hopes that Apple's efforts would contribute significantly to khtml, of course Apple is going to taylor the project to their needs - not the needs of everybody. There's no gain for them in that. To expect otherwise is unrealistic. khtml can use these changes or not use these changes, that's its choice. If it decides not to go along with Apple (or if it can't), that's fine. Nobody should really complain about what either company/group has done.
-Daniel
Is an unrealized danger of OSS that others may take your project in a direction you didn't intend?
No, because that isn't a danger and doesn't hurt you in any way. If you're worried that your feelings might get hurt over something like this, though, perhaps open source isn't for you.
Secession is the right of all sentient beings.
Check out gtk-webcore; their browser (osb-browser) is incomplete, but the renderer is great. I was able to load Google Maps with it and zoom in, something I haven't managed to do on konqueror. There's also atlantis, which seems to use gtk-webcore--I haven't tried it yet.
So... if Apple's code is so hard to work with, how did these people get it working? And using gtk, no less! Sorry folks--I'm no Apple fan, but Apple definitely *is* releasing code, and it *isn't* unusable.
pb Reply or e-mail; don't vaguely moderate.
I wonder if this would be as big an issue if Apple had started out by saying, "we want to fork the code." The license gives them that right. This is essentially what's happened. Neither team is actively using the others patches.
My experience is that merging code on large projects is a pain. Even when you share the same respository (CVS) and have teams working on different branches. I hate the thought of trying to merge code that's several months apart developmentaly. Besides just dealing with the code, check-in comments, when they exist, are usually vague, brief, and overly broad (25 files modified, the comment only actually refers to two of them).
It sucks, but, they might be better off just accepting it as the fork that it is. Both of these teams have differing objectives. Trying to keep the code in sync while trying to (in all intents and purposes) create different end products may be more pain than its worth (to all parties).
The developers of KHTML should be proud. They created an excellent product. A large company felt their product was of high enough quality to warrant distribution in a mainstream operating system.
----- If communism is a system where the government owns business, what do you call a system where business owns govern
What actually happened, was this: KHTML developer Zack Rusin read one too many uninformed comment on the internets about how awesome the cooperation between KHTML and Apple is; being on the recieving end of the very not awesome cooperation, he understandably got a bit pissed off, and blogged about it. The thing to note here is his ire *was not directed at Apple* (recognizing that they were fulfilling their legal obligations, and were required to do no more), but rather at the uninformed idiots. This has now been spun, in part by those same uninformed idiots, into the KHTML devs being whiny Apple-haters, and the whole legality question has also been quite predictably confused into it all as well, which was never a part of it.
So far, I have seen exactly one comment on this thread with some understanding of this. it'd be sad, if it weren't so fucking ironic...
Work is punishment for failing to procrastinate effectively.
I can't imagine who modded this insightful. We really need the whole -1 factually incorrect mod.
iPod limited to apple services and formats, functionally a lockin product designed to trap users into the Apple Music Store.
iPods play MP3, AAC, WAV, MP3 VBR, Audible, and AIFF formats in addition to DRM'ed AAC files. Most users never use the iTunes music store. Also, why would Apple want to trap people using a store that they don't make any money on? You have it backwards. The store is a service they operate to make ipods more attractive.
Look and Feel. Apple has always imposed the most limits on the user's ability to customize his computer look and feel of any OS. Conformity is the Mantra at Apple. Individuality be darned.
Conformity eh, you mean like conforming to standards? Try editing the preferences of a program in Windows. What menu are they in? Answer, it depends on the program, they all put it somewhere different. Apple programs (and about 95% of third party programs for OS X) all have their preferences in the program menu and it is called preferences. All of the programs can make PDFs, from the same menu, in the same place. Can you see why that might be desirable? You don't have to hunt for things or remember different keyboard shortcuts, menu locations, menu names, etc. for different programs.
As far as look-and-feel goes, it is easy enough to change with third-party tools if you really want to, but you're right Apple discourages it. They spent a lot of time making things easy to use and don't want their systems getting a reputation for being hard to use because end users set the colors to really stupid things and put crappy bitmaps all over everything. They don't actively try to stop you, but they don't make it easy either.
Open Source. Apple plays lip services to opensource but does not give anything of signifigance back to the community. Darwin in open. Aqua is not. KHTML is open, Safari is not. On and on.
Everything Apple takes that is open source, they give back to. They publish their improvements and changes to WebCore which is what they have done with the Konquerer code. They take a different approach to things and provide a web service that all applications can use rather than just making one browser. You can write a basic browser using WebCore in about 5 minutes because all you need to add is the UI. Since the UI runs on a different window manager and rendering environment than Konquerer, the UI work is useless to them anyway. How about zeroconf? Apple wrote it and even provided a port for windows users. It is open and the protocol has been incorporated into printers, modems, routers, Tivo, etc. How about the new LaunchD daemon? It is a real improvement to a core UNIX service and not so different from the advanced schedulers used in some very expensive proprietary Server OSes. Linux can take the code and use it, or implement their own version using it as a reference. That does not include the patches they have submitted to Apache, MySQL, and dozens of other open source projects. It sounds like they are giving back to me.
Apple's image is ALL marketing spin.
Yeah, because contributing to open source is such a huge marketing fiat. Get real most people neither know or care what Open Source is and Apple sure as hell is not getting many sales by tricking the Open Source community into thinking they are helping the movement. Apple uses open source code because it works and they give back because it is in their own best interests. That is how open source works. Your view is severely myopic. Try reading some mainstream news for a change and seeing what the really real world thinks.
How is this a 'danger', that other people do other things with a project that you have intentionally given the world the right to work on?
is competition good, or is duplication of effort bad?
Apple has always imposed the most limits on the user's ability to customize his computer look and feel of any OS.
Actually, Mac OS X is extremely customizable down to a very low level. Apple doesn't give you a nice GUI for making these changes, because they consider the look and feel a brand, but neither have they made any deliberate effort to prevent people from providing the missing components. In fact, if they didn't hold their developers responsible for maintaining that look and feel it would be harder to go in and modify the GUI.
The company that is currently doing the most to take advantage of and develop the various hooks Apple has provided is Unsanity, and Shapeshifter is the premier tool of this type:
http://www.unsanity.com/haxies/shapeshifter
But there's also an open source project:
http://themechanger.sourceforge.net/
And there have been other applications going all the way back to Kaleidoscope on Mac OS 8. These apps don't just change the window borders, they change every detail of every control in every application... and Kaleidoscope did it first.
or forking. Forking implies someone with different goals/ideals starting a new project in keeping with those goals/ideals. As near as anyone can tell the Safari projects goals are perfectly in line with khtml's, it's just the corporation making things a little rough around the edges. What's bothering everyone here is that if it was just between projects then there's no technical, legal or political reason everyone couldn't just play nice together. Having a large corp involved is complicating things. This isn't necessarilly the end of the world. There's people at Apple no doubt trying to work this out.
At any rate, if people don't complain a bit, how's Apple going to know we want them to shape up the code a bit.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
One of the best insights from the outside into this whole mess of Apple vs KHTL I thought was made by Gregory Block: I just wonder how realistic the KDE guys are being about this, in the back of my head. Qt is a cross-platform UI, sure - but it's no different than any other UI when it comes to the fact that it's embedded all the way through the application. Is this about Apple modifying KHTML in ways that embed it with Apple UI calls? Is it any different than the KHTML guys embedding Qt in it? Having seen Netscape's cross-platform troubles from the inside, I can see why my gut reaction is that "cross-UI + cross-platform = total mess", because Nav 4.0's cross-platform stuff was... complicated, to say the least. Littered with #IFDEFs and a complicated build system to make that work, where each team routinely broke the mac build, over and over again. The fact that Apple has gone so far to build a Qt-alike API in order to keep KHTML in the state that WebCore is in - which the KHTML players seem to feel isn't good enough; isn't close enough to the Qt version - is already a huge gift that, given that past experience at Netscape, I have difficulty seeing as a long-term solution. So what's the answer? Is Apple expected to build and maintain a full Qt emulation library, or switch to Qt entirely? Is that a reasonable expectation? If it is not a reasonable expectation, is KHTML willing to spend its resources abstracting away its dependency on Qt? And is *that* a reasonable expectation? Or is Apple meant to do the abstraction, as they're the ones "who require it", and submit that back to the KHTML guys and hope that the dev team finds it acceptable? And if they don't, what happens next? And will all parties be willing to live with the performance problems, if any, that come from inserting that abstraction? Will both sides be willing to live with the resulting limitations that come from the differences between the systems? Talking about how the two sides 'differ in politics' misses something fundamental - the codebases appear to have fundamentally differing strategies, and I can't help but feel that I'm not actually hearing proposed solutions from the KHTML side - just issues with what's being done. I can't see how it can be done radically differently without endangering both products, as an outsider. The choice is either to move towards a Mozilla-like platform abstraction, or end up with a Navigator 4 #ifdef-hack. Sure, maybe there's a middle road, but all I'm hearing from the KHTML team is that they can't run WebCore diffs against their tree and are a little on the cross side about it. What would a diffable WebCore look like, and would the KHTML developers be able to live with the product that inevitably created? KHTML will have to change to meet requirements from the outside, requirements that may well be unacceptable to the KHTML community - and vice-versa; what then? Especially after what happened to the last Frankenbrowser? Netscape 4 is dead. Netscape 6 (Java) is dead, with its shelf still in the box. Netscape 5, dead. Everything that was left of 4 that wasn't part of the low-level cross-platform or security toolkits used by every other product went the way of the dodo, along with every attempt to build a new Frankenbrowser, aside from Mozilla - and Mozilla is what it is not only because of the decisions it makes about its architecture, but because of its xplat requirements. And I know that Hyatt knows that, because he was the guy who had to fix the browser over, and over, and over, and over again, every time one of the Windows guys checked in a change to Nav that broke the Mac. If I were him, I'd be strapping a rocket on my back to get away from any hint of a mote of an idea of a glimmer of a thought to return to that kind of cesspit of a codebase, and I can't imagine the KHTML developers would want that life for themselves either. Something tells me that neither side will be willing to sacrifice the one thing that made them stick with KHTML in the first place - the fact that it didn't have all of the cruft that c
If they would just shut the hell up then we could look at Apple as what they are, a passive OSS user.
You have obviously never looked at how companies that are really passive open source software users behave. Microsoft, for example.
Right now Apple is putting some really interesting code out there for people to pick up. They've provided a framework in darwin for completely changing the way UNIX systems are managed, in nicely packaged tools like launchd, complete with "configure" scripts ready for dropping in peicemeal or packaging for debian or Red Hat.
There's a whole damned revolution waiting on opensource.apple.com and nobody's paying attention to it. Why? because it's from Apple? because nobody knows it's there? Because it's not the Linux Way? I don't know. You tell me.
they're complying perfectly with the license the code was released under. why the hell would you expect more?
"The fact that KHTML wants to take their sweet time and Apple wants to get the patches done fast and out the door shows where the divergence is. Apple can't afford to take the open source approach of spending 5 years in beta before releasing the next version."
This is quite ignorant. There are, admittedly some OSS project that are perpetually at a BETA stage. KDE is not one of them. KDE 3.4 had a few weeks of beta testing, and then it was released as final. Just as Tiger. Yes, there were a few bugs found since RELEASE - just as there were bugs in Tiger, and probably there will be more till the next release.
KDE developers did everything they could to help cooperation - in vain. And they don't even regret that as much as they regret that there are clueless users who overestimate APPLE's contributions.
And this makes hardly any sense:"Once again a choice by KHTML. The patches are there, but they choose to do the patches their way, thus eliminating Apple patches." Excuse me? What were you trying to say?
Mods: congrats!
You are mistaken. The provision for making source available applies only to people to whom you have distributed binaries. It says so right here: