1. Welcome to the new MacRumors forums. See our announcement and read our FAQ

Open-source divorce for Apple's Safari?

Discussion in 'MacBytes.com News Discussion' started by MacBytes, May 12, 2005.

  1. macrumors bot

  2. macrumors 603


    Reading the article, it seems that apple could have made more effort in helping KTHML, especially when putting back the changes to the project. In other places I've read about this - its one giant mess that takes an age to merge.

    Unfortunate that Apple couldn't co-operate more with the KTHML community.

    If Apple do drop KHTML, I'm wondering if they can come up with a equally good HTML Engine ( with excellent CSS compliance ), and how fast. This is an absolute must, any webcore must follow good W3C standards, otherwise result in the mess that IE is.
  3. macrumors 603


    Or here's a thought. Instead of reinventing the wheel how about using the already proven Gecko engine that FireFox is built on. :rolleyes:
  4. macrumors 6502a


    That gets them absolutely nowhere. Then, instead of the KHTML guys being bitter about the poor patches Apple provides it will be the Gecko guys. Simply switching to another opensource project will do nothing. Apple really does either need to commit to providing (easy to integrate) patches back to the projects they borrow from, or to just cut out and go their own way. Obviously, I think everyone involved, with the exception of Apple, would prefer they just cooperate more. Reading some of the mailing lists about how Apple provides the KDE guys their updates was pretty interesting, and I feel bad for them.
  5. macrumors 65816


    There are always two sides to a story, and I would be curious to hear the other side from this one.

    Given that David Hyatt, the head of the Safari team, comes from the Open Source world (creator of Chimera, and one of the major Mozilla contributors) I find it hard to believe he would want to screw the KHTML people over.
  6. macrumors 65816


    I think the problem with gecko in the first place was they decided it was too heavyweight / hard to edit for their purposes. Assuming that hasn't changed, it still wouldn't be considered a viable option.l
  7. macrumors member

    Read the article again...


    Apple isn't talking about dropping KHTML in favor of something else. They are telling the KHTML folks to drop their codebase and start working on working on webcore (a KHTML branch).

    Sounds like M$ Embrace and Extend practices to me...
  8. macrumors 65816


    Depends. How are they planning on licensing webcore?

    I'll admit I didn't read the article. I looked at Hyatt's blog and he points out the problem is the changes are wider than just khtml. It their solution is to license webcore with an OSI license, and give all of that back to the KDE community, that would not be a microsoft embrace an extend, but instead would be a company trying to work with the open source community.

    Currently webcore is more advanced than KHTML.


    Okay, I actually read the article this time. The KHTML team's problem is that they had different priorities than Apple, and as such Apple forked it so they could go in their own direction. The complaint is that Apple's fork has diverged enough that it's no longer easy to incorporate the changes into the main KHTML tree, so Apple has suggested that sicne their fork is more advanced, why doesn't everyone shift to that one.

    That all makes sense. I can understand the frustration of teh original KHTML developers, but this is the whole point of Open Source -- two groups with different goals can head in different directions and see who gets there first. I don't see this as Apple playing unfair, any more than the egcs team was unfair when they forked gcc, because they didn't like the gcc direction/speed.
  9. macrumors 6502a


    I definately don't think Apple is operating maliciously. However, it is easy to envision that Apple's business practices and patching habits vary greatly from the OS developers whose work they utilized. The KHTML developers are getting buried in patches to Apple's code that is provided to them in a nearly impossible to integrate way.

    The amicable solution would be for both parties to sit down and get some sort of compromise going on this whole ordeal. Otherwise, it may be in Apple's best interest to switch over to its own codebase, as was mentioned. This "Apple's not sharing" stuff is bad PR for a company that loves PR. And none of that is to say that Apple is required to provide patches and code updates to the KHTML team in a better format. Technically, Apple is fulfilling its duties. It's just not being very generous about it, which I think is what the KHTML team expected.
  10. macrumors 65816


    I just edited my last post, I see know what's happened. Apple forked the code, and their fork has diverged enough that it's not easy to integrate. Honestly I don't see Apple having a moral obligation to provide patches to the original tree (there is a long precedent in the OSS community of things like this happening). The offer to join their fork makes sense.
  11. macrumors 6502a


    The most interesting thing from all of this is the KHTML team's comments that Apple's bugfixes and such are substandard. They said they're used to making the fixes "the right way", so many of the fixes, even the portable ones, are useless anyway. I'd be curious to see if Safari's code's becoming a tangled mess that Apple'd like to dump for their in-house solution.

    In any case, OS developer's are a proud bunch. If Apple's offer to have them help develop their WebCore doesn't involve it being GPL'd, or licensed under something similar (not one devised by Apple), in all likelihood they won't touch it.

    BTW: This made Slashdot.org - http://apple.slashdot.org/article.pl?sid=05/05/12/1555240&tid=95&tid=121&tid=3

    A lot of the KHTML developers frequent there, so it should be an interesting set of comments.
  12. macrumors 6502

    GPL, same as any project based off of KHTML.

  13. macrumors G3


    I might suggest that people ignore the C|Net story, and instead look through Hyatt's blog, and related comments and trackbacks. Both teams know that there is a problem, and the idea of starting over using WebCore as a baseline is only one of many proposals that have been tossed around. C|Net are being a just a little sensationalist here :mad:
  14. macrumors 65816


    Now that I see it's simply a fork of KHTML I realize that, although isn't most KDE code LGPL?

    It looks to me like philosophical differences on coding style lead to this, which is understandable. Lets see how it gets worked before any judgements are made.

    I won't bother reading the Slashdot comments. There are way too many ant-Apple trolls, and just generally completely uninformed people posting there. It's not worth the cost of blood pressure medication.
  15. macrumors 6502

    Sorry, you're right, it's LGPL. Either way, it's not like they can close it off.

  16. macrumors 65816


    Yup, my point exactly (one I bothered to find out what they were talking about).

    So we're not talking about a Microsoft style embrace-and-extend, but about a very common situation in Open Source -- one team thinks another is moving too slowly and forks the code. The other responds that the fork isn't being careful enough, and you get a public spat. Eventually the better side wins out. It's happened with gcc/egcs. It's happened with XFree/X.org. It's even happened on the Linux kernel. The only difference here from the many times this has happened in the past, is this time one side is a multi-national company.

    That's why I won't touch the slashdot thread ... the fact that this is the same forking that always happens is going to be completely missed by the trolls.
  17. macrumors 603


    That was the theory back when Safari was just a rumor. Would have been nice (proud user of FireFox on both platforms), but I can see why they wouldn't want to do that. Not saying it's bloatware, but Gecko is (was) more complicated, and I think they wanted to start with something leaner (which made early Safari pretty fast, but low on features). I'm sure I'm simplifying, but going with a FF type of browser would have created more problems than it would have been worth, and starting from scratch was probably not a viable ( :cough: cost-effective :cough: ) solution.

    Like I said, I user FF, but I can see why they went with what they did. I just hope they don't screw it up (though who could ever do as bad a job as IE?).

Share This Page