Slashdot Mirror


Firefox Lead Engineer Scolds KDE Project

trent42 writes "Firefox lead developer Ben Goodger has had harsh words on his blog for the KDE project, in light of its public tiff with Apple over the KHTML rendering engine. Goodger says 'Safari's renderer is vastly superior to the KHTML used by Konqueror,' and that the KDE developers should follow Apple's lead and focus more on the needs of users, instead of insisting on software perfection."

43 of 669 comments (clear)

  1. Agile by mfh · · Score: 3, Insightful

    So basically, KDE should read this.

    --
    The dangers of knowledge trigger emotional distress in human beings.
    1. Re:Agile by robertjw · · Score: 4, Insightful

      Tricky thing, those numbers. Every machine Apple sells comes with OSX, 'for free'. They may not be selling their software, at least from an accounting perspective, but their hardware would be rather worthless if the price didn't include an OS to run on it.

      Direct software sales may only be 4%, but software is a much larger part of their business than just the revenue percentages indicate.

  2. Can't wait... by ElGuapoGolf · · Score: 3, Insightful


    Personally I can't wait for the KDE response which scolds the Firefox developers for having such huge and stupid security holes in their browser.

    Maybe the Firefox team should get rid of the glass walls before they start chucking stones at other people.

  3. In a way I agree by baryon351 · · Score: 5, Insightful

    the KDE developers should follow Apple's lead and focus more on the needs of users, instead of insisting on software perfection.

    In a way, I agree. It's comforting to sit down, load an app, and have everything work. Knowing it's not quite perfectly written behind the scenes is a small worry sitting in the back of my mind, but it's smaller than when I have a slightly clumsy app that is otherwise technically correct.

    Not that I think Konq is all that far behind in the user side of things.

    1. Re:In a way I agree by l3v1 · · Score: 3, Insightful

      Knowing it's not quite perfectly written behind the scenes is a small worry sitting in the back of my mind

      Ok, so that sounds like IE's early days. I say "early days" because its flaws are nothing less than eyepopping these days. Anyway, I don't care how well Safari works and how good or bad it is or isn't behind the scenes. What I care for is that Konqueror is very well written, very stable and very fast. I use Konqueror (for browsing) about as much as Firefox, maybe more. I really think the Konqueror guys deserve every bit of appreciation for their long great work. I wouldn't like KHTML being dropped in favour of an engine hacked together by Apple devs.

      --
      I am putting myself to the fullest possible use, which is all I can think that any conscious entity can ever hope to do.
    2. Re:In a way I agree by mmeister · · Score: 5, Insightful

      I don't think there is any real evidence that Safari's WebCore engine is "hacked together" by Apple.

      The patches submitted back to KHTML may be harder to integrated more because the changes made to Safari are greater and in a different direction than KHTML.

      I think there is a bit of arrogance on the KHTML side to not even consider the aspect of WebCore.

      The holier than thou attitude seems very pervasive in the Open Source Community. It's not unlike the Not Invented Here syndrome that many corporations suffer from.

      Apple is offering up their changes but seem to have said "We've made major improvements that can't easily be patched in to the existing base. We offer the opportunity to use this new code as a basis for the future."

    3. Re:In a way I agree by spencerogden · · Score: 4, Insightful

      It think so far the KDE frame of mind has paid huge dividends. 3-4 years ago it was entirely unclear who was building a better desktop, Gnome or KDE. KDE it seems went on a spree of doing hardcore behind the scenes work, with a focus on getting APIs and implementations correct. It felt like KDE was stagnating for a while. With 3.2 and now 3.4 KDE users are reaping the rewards of that effort. New applications are developed quickly, the interface is consistent, and system wide usabilty changes work for everyone.

      I think one of the strengths of Open Source is that developers are not under economic presure to deliver it yesterday. They have usually taken the approach of getting it right. I think this means products are sometimes longer to market, but its a trade off. Its one that can be made in open source, but isn't always availible to a commercial developer, they often need code now, correct or not.

    4. Re:In a way I agree by codemachine · · Score: 3, Insightful

      The problem being that KHTML is not platform independant either. It is quite dependant on KDE. What should really happen is that Apple and the KHTML team together write a portable rendering engine that could be used by both projects (ala Gecko). Unfortunately Apple doesn't seem interested in doing that, and the KDE team isn't necessarily that interested in it either. Too bad, because it woud benefit both groups to have a standard rendering engine, just like it has benefited all of the Gecko-based browsers.

      You know that if something renders in Mozilla, it'll probably work in Firefox, Galeon, Netscape, etc. This is great for both web developers and the browser teams, as it reduces the amount of testing needed (it especially helps the little-known Gecko-based projects that would never get tested against themselves). The KDE project could benefit hugely from having a truly shared HTML rendering core with Safari, as large developers such as Google already make their pages avaiable in Safari but not Konqueror. Fragmenting KHTML/WebCore only makes both less useful to test against, though this hurts KDE much more than Apple.

    5. Re:In a way I agree by AusG4 · · Score: 5, Insightful

      Ok, so that sounds like IE's early days. I say "early days" because its flaws are nothing less than eyepopping these days. Anyway, I don't care how well Safari works and how good or bad it is or isn't behind the scenes. What I care for is that Konqueror is very well written, very stable and very fast. I use Konqueror (for browsing) about as much as Firefox, maybe more. I really think the Konqueror guys deserve every bit of appreciation for their long great work. I wouldn't like KHTML being dropped in favour of an engine hacked together by Apple devs.

      I think you're missing the bigger point here....

      Yes, KHTML is "well written, very stable and very fast". But so is WebCore, which is obviously derived from the same KHTML tree that you care for so deeply... but WebCore is vastly more capable. Sure, the KHTML guys deserve recoginition for their work, but to characterize Apple's fork as "hacked together" is a gross misunderstanding. The WebCore engine is clearly the superior technology and Apple's developers are clearly responsible for the progression that WebCore has made over KHTML.

      The reality here is that this whole mess is nothing more than KHTML's developers wanting to have their cake and eat it to. They welcomed Apple to the table with the hopes of some full time developers helping out with KHTML, but then poo-poo'd Apple's efforts when they realised that Apple was foolishly committed to solving problems for their customers, rather then just writing pretty code.

      This is one of those problems that happens time and time agian with open source projects - the developers become so consumed by making a technically superior product that they forget to deal with the fact that it's functionally underwhelming. There are a choice few exceptions to this rule... great sucess stories no doubt (Linux and Apache come to mind)... but they are certainly the exception, not the rule. Case in point... the Gimp. If I hear one more zealot even try to compare it to Photoshop.... No doubt, the code to the Gimp is probably cleaner,better written, and less prone to memory leaks.... but it doesn't change the fact that Photoshop is light years more advanced (4 letters: CMYK) and a lot more elegent to use.

      Of course, what really bothers me is when these inadequecies are overlooked by zealots who disregard ease-of-use and functional elegence because they appreciate the idealogy of the developers. What kind of brain-dead reasoning is that? If "poorly" designed code -works better- for the end user, than it's not so poor afterall. This is the key point the KHTML people have missed.

      At the end of the day... If the Konq guys absorbed Apple's changes, rather than crying about them, you certaintly wouldn't be complaining that suddenly Konq was a whole lot better than it was -before- Apple got involved, now would you?

      --
      bash-3.00$ uname -a
      SunOS panda 5.10 Generic sun4u sparc SUNW,Ultra-2
  4. Uh.. by Thyamine · · Score: 4, Insightful

    So the two are mutually exclusive? We can only have software that is perfectly written or software that addresses the needs of the users?

    Can't we figure out what the users need, and then deliver excellently written software to do that?

    --
    I will shred my adversaries. Pull their eyes out just enough to turn them towards their mewing, mutilated faces. Illyria
    1. Re:Uh.. by HomerJayS · · Score: 5, Insightful

      This is the classic software development dilema.

      It can be developed quickly, cheaply, or correctly (but you may only pick two of the three options)

    2. Re:Uh.. by Skye16 · · Score: 3, Insightful

      I disagree. It's much harder to clean the code after it's already implemented and integrated. Do it right the first time and you don't have to worry about it later. In the mean time, you have a stable, secure product that people can rely on, even if they don't have the latest and greatest features.

    3. Re:Uh.. by EastCoastSurfer · · Score: 4, Insightful

      Do it right the first time and you don't have to worry about it later.

      Assuming you know the right way the first time you do something. Software isn't static, and nearly all requirements are fluid. By the time it's done right the requirements have changed and what you've done is no longer what's needed.

  5. User Needs vs Software Perfection by ranson · · Score: 4, Insightful

    "KDE developers should follow Apple's lead and focus more on the needs of users, instead of insisting on software perfection."

    Now I think back to 1995, when IE focused on user needs over software perfection and the following of published specifications. And look what a mess of incompatibility we have today of javascript, css, java VMs, etc. Mainly because M$ focused on 'the needs of users.' No thanks, I'll stick to the specs.

    1. Re:User Needs vs Software Perfection by mccalli · · Score: 4, Insightful
      Now I think back to 1995, when IE focused on user needs over software perfection and the following of published specifications. And look what a mess of incompatibility we have today of javascript, css, java VMs, etc. Mainly because M$ focused on 'the needs of users.' No thanks, I'll stick to the specs.

      Utter nonsense. I too can think back to those days, and no browser was following the specs. "Netscape is the next Microsoft" was a common complaint, as Netscape piled proprietary tag after proprietary tag into their browser. And don't even think about their initial CSS stab, the web still suffers from that today.

      Cheers,
      Ian

    2. Re:User Needs vs Software Perfection by nine-times · · Score: 4, Insightful

      What about the fact that this all started because Apple created a build of webcore that passed the Acid2 test? I don't think the accusation was that Apple wasn't adhering to standards, but simply that the code was "messy" by KDE standards.

    3. Re:User Needs vs Software Perfection by Johnny+Mozzarella · · Score: 3, Insightful

      Perhaps you missed the story about Safari passing the Acid2 test?

      Safari's code is capable of performing to publish specifications.
      Microsoft's objective was to create their own specification.

      Entirely different thinking.

    4. Re:User Needs vs Software Perfection by Foolomon · · Score: 3, Insightful
      So fine. IE and Netscape were both guilty. That doesn't make the action correct.

      I agree with the original poster's implication that sticking to the specifications is better than attending to the needs of users. The ISO and ANSI committees exist for a reason: when new features need to be added to an existing specification, the committees consider them and update the specification so that all implementers of the specification can do what's "best for the user" at the same time.

      Granted, I'm living in a pipe dream but this is the ideal situation: where the focus on writing specification-constrained (note the qualifier) software is in its extensibility (read: ability to rapidly adapt to new changes to the specification) and performance.

      (Note: this says nothing about portions of software or entire applications even that are not bound by the terms of an approved specification. For example, a POP3 email client has to follow the POP3 specification when it communicates with the mail server but it can add all sorts of features to the client that have nothing to do with the specification.)

  6. Oh holy shit by ErichTheWebGuy · · Score: 4, Insightful

    Do we really need to start another flamewar between projects? Who benefits? Perhaps the KDE project and Firefox should *both* keep their collective mouths shut!

    --
    bash: rtfm: command not found
  7. Heh... by Otter · · Score: 5, Insightful
    [T]he KDE developers should follow Apple's lead and focus more on the needs of users, instead of insisting on software perfection.

    I got on the KDE guys for their bit yesterday, so today I'll point out to the Mozilla side that the reason there was a decent browser for Linux in 1999 was that the Konqueror guys satisfied the needs of users while Mozilla went off constructing a whole new software platform...

  8. Re:Blah... by Skye16 · · Score: 4, Insightful

    Why is this necessarily a fight? Why don't the Konquerer developers just say "you're ugly" and proceed to ignore the other guy? He can have his opinion, they can have theirs, and it's completely useless to argue about it. As a general rule, people don't like being told what to do, especially after they've made an informed decision.

  9. Pissing contests by goldspider · · Score: 4, Insightful

    Ya know, I can't help but wonder if it's silly little pissing contests like this that, at least in some way, prevents OSS from reaching its full potential.

    Here we have several very adept programmers slapping at one another over how their respective web browsers work. Am I the only one out there that finds this kind of bickering trivial and unproductive?

    Yes, people will have disagreements, and people will have different ways of doing things. Fine. But why not harness those different perspectives and create something better?

    As long as OSS projects are afflicted by this kind of petty squabbling, developers' attention will be diverted from creating quality software. Now knock it off!

    --
    "Ask not what your country can do for you." --John F. Kennedy
    1. Re:Pissing contests by Taladar · · Score: 5, Insightful
      I can't help but wonder if it's silly little pissing contests like this that, at least in some way, prevents OSS from reaching its full potential.
      Did the thought ever occur to you that this is the Open Source Process? Discussing the best way to do something and then trying to prove one is right when words don't convince the other side is exacly the reason why quality in Open Source in so high. If you don't allow anyone to critize you your software will never be of optimal quality.
  10. Odd.. by 0x461FAB0BD7D2 · · Score: 4, Insightful

    Well maybe as a software engineer I should. But does anyone that isn't a software engineer care? Probably not. Case closed.
    And guess what KHTML's team is? That's right. Full of software engineers. Which is why they care.

    Secondly, developers should prioritise releasing their products on time, even if they "may have to cut corners".
    Software developers in the open-source world make software because they love to. They want to make their project (note: not product) the best it can be. Releasing products on time is straight from the Marketing Department.

    Goodger has every right to give an opinion, but no right to flame others for caring about their projects, much like Mozilla used to, before they gave up a large part of their community.

    Love for a project, not releasing products in a timely fashion is what makes open-source different, and much appreciated.

  11. Re:Blah... by AllUsernamesAreGone · · Score: 5, Insightful

    And this is different from the normal how exactly?

    Quite frankly, I'd rather have them arguing - when OSS developers disagree it often highlights issues that people should really be thinking about.

    You might like the Solid Wall Of Unity approach but give me chaos any day.

  12. No shit Einstein! by 10Ghz · · Score: 5, Insightful
    "Not everyone wants to change the world, but Apple does," he said, "and although they may have done the least required of them in accordance with the licences of the original source code, it was within their rights to do what they did, and no one should begrudge them for it."


    Isn't that exactly what the KDE-developers said?? Sheesh!

    I for one think that it's great that there are still people out there with a goal to create perfect code, and not just slap features together. It's interesting that Apple chose KHTML because the code was clean, fast and small. And now this guys suggests that KDE abandons those benefits and moves to Webcore (which has lost most of those benefits due to cutting corners and less than perfect code).

    Is that it? Crummy code that is "good enough" is the way to go?
    --
    Lesbian Nazi Hookers Abducted by UFOs and Forced Into Weight Loss Programs - -all next week on Town Talk.
  13. That just doesn't sound right by rsax · · Score: 4, Insightful
    The KDE developers should follow Apple's lead and focus more on the needs of users, instead of insisting on software perfection.

    I can't say I feel comfortable hearing that type of reasoning coming from a Lead Engineer of my favourite web browser. I'm not a Microsoft fan but if an IE developer made a comment like that then geeks would be cutting him or her up for that. I might be wrong since I am not a coder but wouldn't keeping software perfection a priority lead to less bugs in the future?

  14. Some times a little conflict is good.. by Visceral+Monkey · · Score: 3, Insightful

    Personally, I've always liked KHTML but have been frustrated by the lack of any real progress in it's use in Konqueror. Now, is this Apples fault? No, they just built a better mouse trap. This whole thing smacks of the same hurt feelings over the Debian vs. Ubuntu tift. The king is dead! Long live the king! and all that..

    Also, if anyone has the "capital" to expend on criticizing KDE, it would and should be the people who have made one of the most successful browsers out there to put a dent in IE usage. 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 (Debian/Konqueror I'm looking at you).

    --
    *Fortitudo, aequitas, fidelitas.*
  15. He has a point by ShatteredDream · · Score: 5, Insightful

    A large part of the reason that Apple is still around with not even 5% of the market is that they do care about the user. With a user base that small for their platform, most vendors would be dead but Apple focuses heavily on the user experience. I don't see a lot of that at all coming from most open source projects.

    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.

    For all of this bitching about Apple exploiting OSS, I don't see any recognition that the mere fact that OSX's underpinnings are OSS gives OSS a vote of confidence in the corporate world. For one of the two largest platforms in the world to switch to that foundation is a big endoresement and help lend legitimacy to OSS. The funniest part of this is that KDE's developers are finally discovering the fact that forks do happen. Imagine that, Apple actually forked KHTML for their own needs. Why is it OK for X.Org to fork and go off in one direction, but not OK for Apple to do the same thing? They give the patches back and excuse me if I am at a loss as to how a forked code base is going to maintain a lot of similarity with the original when both are going off in separate directions.

    1. Re:He has a point by cowscows · · Score: 3, Insightful

      You're talking about a double edged sword here, namely that the rapid advances in hardware has allowed software to be written much more sloppily, while still maintaining acceptable performance. It's good in some ways, because it allows things to get done faster and cheaper. You could also make an argument that some of the larger projects couldn't be realistically done at all beforehand. A project with dozens of programmers working on it becomes increasingly difficult to coordinate and perfect. Letting the specs of the hardware smooth over some of the bumps makes life easier.

      Then the bad side is that sloppy coding is not only inferior performance-wise, it also leads to maintenance difficulties, as well as security issues. The most notable example being all of the legacy garbage that windows still carries around.

      It sounds like the KHTML people are trying to buck the trend, and make a large, but solid piece of software. They're saying that it's not impossible, just that it takes a while. The "computer industry" has been moving at this incredible speed for a while, so fast in fact that it wasn't realizing a lot of the mistakes it was making. There are plenty of examples of how this is making life tougher now. The KHTML guys aren't interested in doing that anymore, they want to do something right, so they're doing it.

      Maybe they're thinking of their renderer as more a piece of infrastructure or technology more than an end product for your everyday user. Try to draw a vague parallel to some guy writing code for the space shuttle. There's more at stake when you're sending humans up in a rocket, but the mentality can be the same. We want to get this right, on the first try. It's inherently complicated enough , no need to make things any denser with hastily added features and sloppy coding.

      --

      One time I threw a brick at a duck.

    2. Re:He has a point by As+Seen+On+TV · · Score: 4, Insightful

      As much as I like to hear talk like that, a better explanation is that the market is freakin' huge, and 5% of the installed base is still anywhere between 15 and 40 million units, depending on which estimate you believe.

      Everybody likes to talk about how Apple owns such a small share of the market, but in doing so y'all lose sign of the fact that Apple is the fourth-largest computer manufacturer in the entire world, and the second-largest developer of operating-system software. Considering how narrow our focus is, I'd say those are two pretty remarkable facts, wouldn't you?

  16. MoFo getting more like MS by the day, it seems by McDutchie · · Score: 5, Insightful

    From TFA:

    Goodger went on to say the open source community could not accuse Apple of breaching any licences.

    I would not be so sure of that. I seem to recall that the GPL defines source code as the "preferred form" of the program for making modifications of it. If Apple "comments" its patches by referring to numbers in a proprietary bug database to which only they have access, Apple could be accused of intentionally obfuscating its source code, which is a violation of the "preferred form" clause in the GPL. In any case, it's ethically wrong because the free-software concept is meaningless if the provided source code is not realistically usable without having access to essential information about what it does.

    It was important, he said, realise that "no software is ever perfect".

    Secondly, developers should prioritise releasing their products on time, even if they "may have to cut corners".

    Gee, that sounds eerily familiar. Where have I heard it before, that "give Joe Sixpack what he wants and damn software quality" attitude? Marketing fluff at the expense of solidity and security? Oh right, of course, that's the attitude that brought us the virus propagation engine that is Microsoft Internet Explorer. Is it any wonder that Firefox is now on its way along the same route?

    "Most developers probably don't alienate people intentionally ... Over time, software has come to demand an impossibly high level of computer literacy," the Firefox creator wrote.

    Ridiculous. The use of software is demanding less computer literacy by the year -- compare today to the MS-DOS days of twenty years back. But that is in fact a big part of the problem. People should learn to accept that using a computer requires some basic form of clue. If people are not willing to acquire such clue, they should watch TV instead so that they won't harm anybody with the viruses, spam and DDoS attacks perpetrated through their zombified computers.

  17. Re:Blah... by squiggleslash · · Score: 5, Insightful
    Even worse is that Ben doesn't even appear to know what he's criticising. He takes a quote out of context and puts the same spin on it that /. did a few weeks ago, treating it as a criticism of Apple when the thrust of the original piece was protesting that people were assuming that just because Apple had added something to WebKit, it follows that it'd be in the next release of KHTML, and were getting pissed at the KHMTL people when that didn't happen.

    I'm not 100% surprised, given the degree to which the original post was misrepresented, but given some replies to his blog entry pointed this out and Ben's single response to them has been dismissive, it'd be nice to see a sign of good faith.

    --
    You are not alone. This is not normal. None of this is normal.
  18. Re:Blah... by hostyle · · Score: 5, Insightful

    How would you like it if you had a real nice and clean well documented codebase and you gave it to someone for free, the only stipulation - if you make some changes please give them back to us also. The guys you give your code to do make changes and do give them back. Problem is the code they give back is all over the place and badly (if even) commented. Then other people (your users) start complaining "this other guys software is better than yours, but hes using your code. Give us those features NOW." ?

    --
    Caesar si viveret, ad remum dareris.
  19. Re:Blah... by JohnFluxx · · Score: 5, Insightful

    Hmm, we work hard with Apple to give them the best possible access to our code. Apple does the minimum it can in giving the code back to us. Slashdotters praise Apple for the work on html, and so we just ask for people not to praise apple so much since they aren't exactly working with us - they don't use any of the resources we set up to try to encourage them to work with us.

    And now _we_ are the pain to work with and aren't encouraging participation??

  20. Where "free" software fails by putaro · · Score: 4, Insightful

    Ben Goodger has hit on one of the major ways that "free" software can fail and that is that the people working on the project are doing so out of the goodness of their hearts and for their own reasons. Some developers, like Goodger probably, are writing free software for the kick of having as many people use it as possible. This will make them somewhat use oriented. Others, and the KHTML guys appear to be this, are writing code for the sheer joy of writing code. And it's not fun to write stuff that cuts corners just so you can get it out the door. Of course, you may not be meeting the users' needs. But then, there's no requirement to meet users' needs. It's free - if you don't like it, fix it yourself or don't use it. In this case, Apple chose to fix it themselves. The fact that they diverged from KHTML simply shows that they have different priorities and isn't any different than FreeBSD and NetBSD spliiting.

  21. Re:Blah... by ceeam · · Score: 4, Insightful

    It's actually a known phenomenon that "real nice and clean and well-documented codebase" can in fact be _evil_! Because everyone except really lousy coders are afraid to touch it. "It's so beautiful it's practically dead" one could say.

  22. Re:Blah... by mmeister · · Score: 5, Insightful

    There is no such thing as real nice clean, well documented codebase, at least not forever.

    These attributes naturally go away as you add functionality to any code. That is a fact of software development.

  23. Don't Follow Firefox Adivce: considered Bad! by kupci · · Score: 3, Insightful
    What the Firefox guy is forgetting is that he wouldn't be where he is had he followed his own advice. Has everyone forgotten the beating Mozilla took when they scrapped the Netscape code and decided to rewrite the layout engine from scratch? While they strived for making their browser superior, IE blew past them in the marketplace, building on the existing (Spyglass?) foundation which was "good enough". Now finally the wisdom of that choice has come to fruition.

    The original Mozilla browser, first released as Navigator 1.0, was developed rapidly by a small team that was passionate about creating the next killer app -- and they succeeded wildly. Now that the web has evolved, Netscape has assembed the finest team available to redesign and redevelop the next generation layout engine upon which it will build future products. Gecko enables a pioneering new class of dynamic content that is more interactive and offers greater presentation control to Web developers, using open and recommended Internet standards instead of proprietary APIs.
  24. Re:Mutually Exclusive? by cowscows · · Score: 3, Insightful

    They're mutually exclusive if you want to work at the pace that the computer industry tends to move at. Doubly so for a bunch of volunteers working for free.

    I guess that makes the assumption that the needs of the users includes a rapidly expanding feature set and whatnot. And while that is important (particularly if you're going for marketshare), there are still users who'd rather have some good code. Not to mention that eventually the bad code may catch up to you, and cause the needs of the users to change. Windows needed a lot of usability enhancements until the Win95-98 era. Then stability became a big issue. MS ironed a lot of those problems out, and now security and spyware is the big problem. A lot of those issues could have been mitigated by better code at earlier stages. Fortunately for MS, their monopoly has allowed them to advertise their security and spyware solutions as new features, and so a mostly under-informed public still thinks they're paying for innovative work.

    But returning to the original point, even for a big, well funded company like MS or Apple, it's not really possible to write perfect software fast enough to lead the market in features. You can dump more money into it, and hire more engineers, but that just makes it all the more complicated and harder to coordinate, leading to more mistakes.

    The KHTML team can avoid that because they're not trying to keep a business profitable, they're writing this stuff because it's a hobby for them. Personally, I try and keep my hobbies as free of deadlines as is possible. And if anyone wants to criticize how I indulge in my hobbies in any sort of non-constructive way, they can go to hell, I'm not interested.

    --

    One time I threw a brick at a duck.

  25. Tests are no substitute for good design by expro · · Score: 4, Insightful

    I am sure to be modded OT as this whole thread is, but...

    The Agile/XP movement is warped at best. Tests are no substitute for good design and they cannot prove any useful level conformance to a design (except in an extremely trivial application). Tests are useful in many cases, unless they are used to rationalize bad practices based on false notions.

    And the more extremists you have trying to force it to be so, the worse the XP/Agile movement is percieved. Sure, they picked up on parts of a number of good practices that good programmers already followed, but when will they stop twisting them and advocating that experienced programmers abandon principles of adequate forward-looking design and methodology and follow the way which is what they ultimately believe to be The Only Right Extreme Way.

    They resemble the pointy-haired managers who would like to think they can substitute their process for masterful programming and design.

    I was attracted to XP by their advocacy of some of the more-reasonable principles until the fanatics showed why it was really called extreme programming. They need apologists to start really apologizing.

  26. Apple offered, but KHTML didn't want to. by Paradox · · Score: 5, Insightful

    Apple is on record for offering to jointly attempt to make the important parts of WebCore cross-platform, similar to the situation with Gecko.

    The KHTML team turned them down. They probably did so because it would shift the focus away from the KHTML they know and love and more towards the more realistic (but messier) WebCore, which they don't seem to want to do.

    The KHTML team doesn't even seem to want many of the changes. Apple makes a product, and they don't care if they break small things to make deadlines. KHTML is a product of the opposite school, preferring to make a very small, clean codebase. The price of this is feature deficit.

    This isn't about Apple being evil, or KHTML being snobs. It's about a project being forked. As time goes on, Apple has less and less to offer to KHTML. WebCore and KHTML are diverging, and people seem to be upset about this. I can't imagine why, this sort of separation was inevitable. Apple's best interests are served by leveraging their own excellent environment, and every time they do, they further exclude the KDE project.

    --
    Slashdot. It's Not For Common Sense
  27. Re:Blah... by Jimithing+DMB · · Score: 3, Insightful
    how has KDE/KHTML been hurt by Apple's actions?
    Look around you

    Bullshit. The KHTML developers brought this discussion on themselves. Apple rightfully took the code, incorporated it into their products, and not only made the modified version available to users of their products but also publicly for anyone wishing to download it.

    It appears that the KHTML developers expect Apple to do all the integration work for them. There is nothing in the LGPL that requires this and my reading of both the LGPL and the GPL indicates that requiring modified code to be made available is the spirit of the license. Integrating it back to the mainline is a courtesy but the license specifically does NOT require this.

    Sure, it's customary to help integrate it back into the mainline tree but there have been other instances where this hasn't happened. For example, read up on Lucid Emacs (XEmacs) vs. Emacs debacle. You can draw many parallels from that to this. In that case Stallman was working on releasing a new version of Emacs for years and hadn't done it. Meanwhile, Lucid needed certain features and implemented them. When they offered to integrate the work back to mainline Stallman rejected it because he had his own ideas of how it should be written. In addition (and this does not apply in this case) Stallman required copyright assignment to the FSF which was something Jamie Zawinski in particular did not agree with. After much back and forth Lucid gave up and thus the XEmacs fork was born.

    The Lucid Emacs developers suggested that their code simply be incorporated into the next Emacs and that if Stallman wanted to rewrite it again that's fine but what they had was already working and better than what was in the tree. Stallman rejected it because he preferred to wait until their rewrite was complete at which point Lucid could try to integrate with the rewritten code.

    It should be obvious that this is a *really* stupid decision. The KHTML developers should suck it up and realize that Apple now has a better rendering engine than they do. They should merge in the changes now (including the ones they don't like) and THEN decide to rewrite things if the code is problematic. In the meantime the KHTML users have a better browser. It will take just as long to write code regardless of whether they merge in the Apple changes or not.

    This basically amounts to the KHTML developers having a serious case of Not Invented Here syndrome. After trying and failing to get Apple to do the merging work for them they cried foul and posted publicly about how Apple wasn't helping. I'm truly glad it has mostly backfired because it's up to the KHTML project to decide whether they want the code or not. It's not Apple's responsibility to take orders from the KHTML developers. If KHTML doesn't like it then WebCore can remain a fork of KHTML just like Lucid Emacs is a fork of Emacs.

    And don't give me any of the shit floating around here about how the KHTML developers merely wanted to point out that Apple wasn't doing the merging work. There are claims in this thread that the KHTML developers are fine with that but they just aren't fine with it looking as if Apple is contributing to KHTML. Well, news flash, Apple *is* contributing to KHTML and if the KHTML developers don't like the way they contribute and didn't want a big media fuss about it then they should have been smart enough not to write about it publicly. It is for this very reason that I *don't* keep a journal on the web.