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."

Comments

Agile

[mfh]

So basically, KDE should read this.

Re:Agile

[revscat]

Apple sells hardware. KDE is a developer-first focus. They profit stricly on developer sales. Not hardware, sales, as Apple ..

I'm not 100% certain, but I *think* Apple sells software, too. Stuff like OS X, iWork, Final Cut Pro, DVD Studio Pro, Motion, iLife, WebObjects, Shake. From all evidence that I can see, that's software.

Re:Agile

[Ozwald]

Other way around, dude. Agile methodologies come from open source ideas, like release often, listening to customer (or other developers).

Remember what it was like before Agile? Companies and consultants would develop big blocks of software, check it in, QA it, and show the customer who'd get pissy because it didn't work the way they expected. Yes, Agile prevents that. But seeing what is happening, I'd say that KDE does is very Agile, unlike what Apple just did.

Oz

Re:Agile

[cosmo7]

You're quite right; I apologize for besmirching you.

It is interesting that Apple's policy of giving away software - principally OS X - to sell hardware means that from an investment analyst's viewpoint the company's stock is expected to have a much lower P/E than if it sold the software separately. Companies that sell software can have huge P/E ratios.

Re:Agile

[robertjw]

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.

Can't wait...

[ElGuapoGolf]

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.

Re:Can't wait...

[Anonymous Coward]

LOL, trust me, if KHTML had the user base of Firefox we would be seeing security holes. Probably worse holes even.

It's just like how Mozilla/Firefox had gone on for years and years without much in the way of huge security hole announments. Only recently have be begun to see the problems. To assume they weren't there before is naive. It's just that not enough people used it or cared back then for it to matter.

Re:Can't wait...

[Skye16]

I don't trust you, because you make the assumption that the software engineering practices are the exact same. You can never completely remove all security holes. But you can reduce them. I'm not saying Mozilla does a bad job at all, but to automatically say that KDE is just as bad, but doesn't have the userbase to expose it, isn't logical. It may be right, but there are other factors to consider; factors which you don't seem to pay any attention to.

Re:Can't wait...

[cloudmaster]

Because it's impossible for Apple to miss a security problem. What, there were security problems in other apps that Apple bundles, several of which were fixed buy the original authors, not apple? Oh, Ok.

I guess there aren't any remaining holes in Apache, Samba, or Cups, because the all powerful Apple is bundling them with OS X.

Re:Can't wait...

[LWATCDR]

Actually KHTML has the biggest security hole of all. It does not follow current standards so there are time when you HAVE to use another browser. So in effect you have any security holes in KHTML and what other browsers you are forced to use.

I actually like the KDE browser better than Firefox. I love the built in spell check and it is fast.
But I can not use it with Google maps or the full version of gmail.
Has Safari introduced any huge security holes? The latest Firefox hole seemed less that huge to me. Yes it could be exploited by a white listed site but the only white listed site I have is Mozilla.org
It was also patched very quickly.

Re:Can't wait...

[willCode4Beer.com]

I personally can't wait for the next KDE/Apple slashdot flamewar.

Are the editors just doing this for kicks? I have to admit, I've gotten sucked in and made the comments too.
First, we get repeated Evolution vs Intelligent Design debates until everyone was sick of them. Now, its the Apple/KDE. Maybe after a week we'll get ad naseum:
Apple rocks/sucks
Linux vs Windows
Java vs world
OOo using java
Your favorite open source product has new security hole
Your most hated closed source product has security hole

wha, I just saw a comment that got me riled up, KDE ro... Apple, wha.. let me go straighten out that troll...

Re:Can't wait...

[tveidt]

> The only troll here is the Firefox developer.

You did not read his blog entry, did you?

Re:Can't wait...

[masklinn]

AFAIK Javascript is not "standard free".
Javascript itself has been standardized by the ECMA as ECMA-262 (ECMAScript) ever since Netscape donated the language to said ECMA (even though ECMA's work blows and no one ever read the normative definition because it sucks donkey balls), and W3C's DOM and DOM Events have extensive documentations [u]including documentations on how you're supposed to implement ECMAScript bindings[/u].

And that's not to mention really good reference sites such as QuirksMode, which is pretty much a Javascript bible (only sound, logical and actually holding relevant information... not a bible at all after some more thought).

Now if we specifically consider GMail and Google maps, they're not using only standardized javascript, they're using a feature called XMLHttpRequest which isn't normalized (and isn't even Javascript everywhere, the only way to use XMLHttpRequest-ish code in MSIE is to create ActiveX objects), and about that very command your point (about the lack of normalization) stands true.

BTW Google Suggests also uses XMLHttpRequest

In a way I agree

[baryon351]

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.

Re:In a way I agree

[l3v1]

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.

Re:In a way I agree

[mmeister]

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."

Re:In a way I agree

[torpor]

yeah, this is a valid position. KDE must pay more attention to users.

however, there is another position, overlooked by this so-called 'debate', which means it does not matter, for now, that KDE 'ignores use in favour of programming practice', and i personally thing Goodger is degrading the importance of this, a little, to 'prove some other point'. he's missing a point, and can't possibly be ignorant about it.

the other position? developers. period.

sure, its nice that apple are able to sling out the code and write Simlpy Great apps, that work, the way apple apps should. they've been doing this for years, this 'making user-friendly software' stuff. it is to be expected of Apple. (not necessarily of KDE.. yet.)

but for any developer who has stuck his shingle on the apple bandwagon, their inattention to the 'cleanlines' of API's and methods, and such, in some area's, has been a real bear to ride.

as a developer into apple, its been a good-looking and fun one, because Apples SDK's have always tied to you-know-it-works hardware, but a bear nevertheless. apple haven't really been super developer-focused until recently, in my opinion...

whereas, on the other hand, KDE is not just about users .. it is about use, of course and definitely, but also KDE originally, if i remember, started simply to make it easier to develop software for unix systems [linux,*bsd,etc.], and this is really a developer-first focus.

these platforms are not Apple. they are not Microsoft. different power buss in the code-group structure. different power requirements. slower at some things, faster at others.

linux/OSS/KDE is a developer-oriented approach to the issue of developing software, first and foremost. there is no 'Hardware Sale of KDE', in the way there is 'Apple Sale of [insert Apple-commercialized OSS app/library] running on [Apple Hardware]' .. yet.

KDE exists to put a friendly interface on Unix.

and .. well .. that is another factor: hardware.

Apple sells hardware. KDE do not.

comparing KDE to Apple is one thing. but its 'Apple' versus 'Oranges' really, because Apple exists to sell hardware to the user who would not normally use a computer, or have one.

You, typically (so far) only come across KDE causatively, which is to say that KDE is far more DIY than Apple, anyway .. no newbie is downloading KDE/using KDE, its a certain 'hacker type' of person on the KDE front so far, coders and skilled users, for the most part, able to contend with active daily use involved in KDE dynamics.

Diametric opposite 'market sphere', so far, to that of Apple, so far.. i keep saying so far, because i see things on the KDE front that will out-strip Apple, in terms of sheer numbers, soon enough.

the reason this article resonates is because it pitches KDE versus Apple. (eh, KDE versus Apple? who would ever have thought Apple would be The Unix Vendor of Choice in the 21st Century?)

(SGI ought to be making laptops that run KDE, i mean, sheesh..)

so yeah, it is KDE versus Apple. and it is because Apple is focused on this Hardware Sale Aspect, first and foremost as an organized structure of people, and KDE is focused on developers and development, that you cannot compare the two fairly.

anyway my point is, to the KDE and other camps: developers.

developers, developers, developers. sell hardware.

[/monkey-boy back in his cage..]

Re:In a way I agree

[Jason Hood]

Also keep in mind that KHTML and Konqueror are two separate projects. Konqueror is probably the most usable browser of all time from a functionality standpoint. User interface wise, it could be better. but its no worse than FF or IE. Once gecko is properly ported as a kpart, konqueror will be extremely powerful. being able to switch between renders on the fly, saving sessions will be awesome. It may actually kill KHTML, although KDE devs firmly deny that =)

This argument made more sense 3 years ago. Then KDE was laying the foundation for 3.x and focusing little on the UI (In my opinion). Now with Qt4 (seriously, read the new featureset) and KDE4 due out in a year, KDE/Konqueror/KHTML is going to get a major boost. In case anyone hasnt noticed, KDE and Gnome have been exploding in the last 2 years.

Now if I could only get a Mac clone theme for KDE ;)

Re:In a way I agree

[Infernal Device]

This case highlights a huge difference between the corporate world and the open-source world.

If you write software for the sake of writing software, as is generally the case with Open-Source, then it's perfectly alright for the emphasis to be on software quality. You're not really on a deadline - no one expects you to cough up code quickly and if it breaks, well, it will get fixed, but anyone bitching about it - they got what they paid for.

If you write for consumers, as in the corporate world, then the emphasis has to be on speed and getting the code out there. Otherwise you lose potential customers and mindshare, all of which is vitally important to a company. If it's broken, you fix the stuff that people are bitching about the most because if you don't it could really screw you in the short or long run through bad reputation and lost sales.

This dichotomy to be addressed by both sides when corps start working with Open Source projects. When one side can't be rushed and the other side is all about rushing, you need an arbitration procedure.

Re:In a way I agree

[spencerogden]

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.

Re:In a way I agree

[mattyrobinson69]

Baghira.

it has the panther, tiger and something else themes

Re:In a way I agree

[BlueStraggler]

Your post would be much easier to understand if your sig came first.

Re:In a way I agree

[iamacat]

Along comes some big company that grabs your code, renames it, and puts it into their product publically. They submit some patches. Then, they basically stab you in the back.

Slow down cowboy, I think you are talking about SCO here, not Apple! Someone creating a new project based on your free code is a compliment, not a stab in the back. KDE developers should just take any portion of Apple's changes they find useful and let the rest stay in a separate project. If later Apple wants to take advantage of improvements in the new version of KHTML, they will then do the work of integrating their own dirty patches without any prodding.

In the meantime, the rest of us can hope for a GNUStep webcore-based browser and saying goodbye to bloated Linux desktop environments that try to look like Windows.

Re:In a way I agree

[codemachine]

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.

Re:In a way I agree

[AusG4]

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?

Re:In a way I agree

[Ogerman]

KDE has chosen a better infrastructure than Gnome ... But Gnome is better in terms of the software they developed.

KDE's infrastructure allows for a modern, well-integrated desktop. It is an example of object oriented principles being properly applied in real world development. Everything is richly context sensitive and there is a high degree of code modularity and re-use. To give a specific example, application file dialog widgets in KDE use the same objects as the Konqueror file manager component. Unlike in GNOME, I can manage files, open a preview pane, access network resources, etc. within the file dialog. KDE has many other similar qualities that GNOME lacks. From a real-world usage perspective, KDE is highly superior to GNOME and it's no surprise why most people running Linux today use it. I would have to say the same for KDE applications -- they're generally much richer because they re-use the superior core KDE components. Examples: I know of no equal equivalents to K3B or Amarok as GNOME/Gtk apps. I also find KMail far superior to Evolution and Kopete superior to Gaim.

KDE tries to look like Windows too much for my taste. Gnome is inspired on the same ideas of Mac OS, something more elegant.

KDE doesn't really try to look like anything - it's a product of what seems to work and what users are asking for. I certainly don't see much similarity to the look/feel of Windows. (Yes, I still run into Windows a bit on the job so I'm still quite familiar..) GNOME is (now) designed upon a set of HCI guidelines developed by a handful of folks who sat illiterate users down at computers, asked them to perform simple tasks, and then decided that this must be the way interfaces should be designed. Obviously everyone else (aka. real users) don't know what they're talking about. The result is agonizingly simple, inflexible, and feature-bare software. That's not to say there isn't some great GNOME/Gtk software but the desktop environment itself is the pits. It's not MacOS X either.. it's more like Mac OS 7 or 8 in feature set / richness. Hardly "elegant" by any standards.

Re:In a way I agree

[Ogerman]

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.

I'd like to point out here that the only reason Open Source development usually takes longer is that, as with KDE, it's largely a volunteer effort. Pay those same high-quality, principles-first developers a full time salary, and I'll bet development is just as fast as any corner-cutting proprietary shop. Open Source needs commercialization but it needs to be done properly.

What Apple did was simply fork KHTML because they insisted upon absolute control. If they had instead hired / contracted with the original KHTML developers, none of this mess would have happened and everyone would have been better off. To blame the volunteer KHTML developers for not accepting low quality patches to their hard work is asinine. The KHTML developers had put an enormous amount of hard work into making their codebase clean. I know from my own experience working with / managing Open Source projects that low-quality patches from outsiders almost always come back to bite you in the future. I blame Apple for valuing control over quality. Timeframe was not the issue.

Re:In a way I agree

[WMD_88]

Gimp 2.0 brought CMYK support.

Take Notes

[PaisteUser]

Now only if Microsoft would insist on software perfection....

Re:Take Notes

[ceeam]

Why, it is _perfectly_ crappy already.

Blah...

[afd8856]

Just what we need. Internal fights between developers for 2 open source projects...

Re:Blah...

[Skye16]

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.

Re:Blah...

[AllUsernamesAreGone]

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.

Re:Blah...

[squiggleslash]

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.

Re:Blah...

[hostyle]

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." ?

Re:Blah...

[JohnFluxx]

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??

Re:Blah...

[10Ghz]

The KHTML guys are really shooting themselves in the foot with this. They certainly aren't encouraging companies to participate with open source projects. The only thing they're doing is reinforcing an existing conception about open source developers -- that they're a pain to work with.

The KDE-developers commented about the USERS who whine when Safari-patches don't get merged in to KHTML. They never whined about Apple as such. They even mentioned that Apple is abiding with the license.

How exactly are they "pain to work with"? Apple got a kick-ass HTML-code from them, with NO questions asked, no price being asked and with zero red tape! How exactly does that mean they are "pain to work with"? If anything, this incident shows that COMPANIES are "pain to work with". KDE-developers REALLY wanted to work with Apple, but Apple wasn't interested!

Re:Blah...

[ceeam]

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.

Re:Blah...

[mmeister]

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.

Re:Blah...

[Jimithing DMB]

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.

Why not

[mattmentecky]

...and focus more on the needs of users, instead of insisting on software

Why not try something completely the opposite, like Microsoft, and focus on neither?

Ben Goodger's blog URL

[Manip]

http://weblogs.mozillazine.org/ben/ Who knows why the poster linked to a ZDNet article (Which incidentally can't handle a slashdotting) instead of the original blog.

Uh..

[Thyamine]

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?

Re:Uh..

[Feneric]

No, they're not, but they often can't be achieved in the same (usually all too brief) time frame. I tend to side with the Apple / Firefox folks on this argument -- fix it first, clean the code second.

It's interesting to note that Apple doesn't seem to have gotten into any significant disagreements with any of the other OSS people they're working with (regarding Darwin, etc.) along the lines of what's happening now with the KDE kamp. That leads a little more credence to Apple now, too.

Re:Uh..

[HomerJayS]

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)

Re:Uh..

[Skye16]

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.

Re:Uh..

[drew]

Of course, Apple hasn't really gotten into any significant agreement with the KDE people either. People who have been paying attention may have noticed the KDE developers saying that although Apple hasn't cooperated with them as much as the might have liked, they are within their rights to do that.

For all that has been said about a feud between KDE and Apple, the real feud is between the KDE developers and the users and slashbots who think that any new features in Safari should be in KDE too, and if they aren't it's because the KDE developers are slow, lazy, whatever.

It's worth noting that (from what I've heard, at least) the other open source projects that apple has used code from haven't gotten back much more in the way of useful contributions than the KDE team has.

Re:Uh..

[OglinTatas]

"...quickly, cheaply, or correctly..."

This is not quite that software dilemma. Lifting something quoted in an earlier post:

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

This is about writing something that is correct to spec by the design document (i.e. the needs of the user--or maybe it is about getting the design document right?) vs. technically correct (i.e. perfect software--correct to the language spec, elegant, robust, no flaws, easily readable and maintainable, etc.)

Ideally, one's software would be both of these, and thus fit in the third category "correct".

I therefore propose that this old adage be modified thus: "On schedule, on budget, on spec, or few flaws--pick two"

Feel free to change those words to make it flow better. OT: in my limited experience, the scope of the project is always changing, so really none of those apply, therefore one can only really try to achieve #4, as few flaws as possible in what actually does get done.

Re:Uh..

[EastCoastSurfer]

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.

Re:Uh..

[ajs]

"You can, however, have a well-designed, well-coded project"

Yes, yes, of course. No one has said "here's a good idea: write crappy code!"

The point is that writing code that is "good enough" should be balanced against giving your users a product which is "good enough" for their needs, and until it is, you should not focus on making the code "perfect" to the exclusion of things like meeting release dates; issuing bug-fixes; etc.

Balance in all things, and when in doubt, favor the user. That's all that's being said here.

User Needs vs Software Perfection

[ranson]

"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.

Re:User Needs vs Software Perfection

[mccalli]

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

Re:User Needs vs Software Perfection

[nine-times]

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.

Re:User Needs vs Software Perfection

[QuietLagoon]

Mainly because M$ focused on 'the needs of users.'

Microsoft did not focus on the needs of the user, they focused on the needs of maintaining their monopoly. If that briefly aligned with the needs of the user, it was purely coincidental.

Re:User Needs vs Software Perfection

[Johnny Mozzarella]

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.

Re:User Needs vs Software Perfection

[Lars T.]

It wasn't even quite that, just that Konqueror users were complaining that it took so long to get those features/fixes too, "when they already had the source-changes from Apple" (for the umpteenth time in a row).

Re:User Needs vs Software Perfection

[masklinn]

I don't know why anyone informed would say this. The CSS in IE6 is kinda bad, but it's clearly supposed to be W3C CSS and not something proprietary.

1- It's not "supposed to be the W3C CSS", of the few properties that are implemented (CSS1, CSS2 is barely scratched) many are wrongly implemented [box model, only fixed in Strict mode IE6] and half the implementation is heavily bug ridden
2- You probably missed all the proprietary MS crap in their implementation of the CSS, such as scollbar shit, that was NOT implemented in a W3C-compliant style (W3C allows proprietary CSS properties, but you HAVE to use precise prefix of type "-name-", which is why you see such things as -moz-outline)
3- CSS in IE6 is not "kinda bad", it's an awful heap of crap and a pain to work with from a dev's point of view
4- And if we extend from W3C's CSS to W3C's everything, MSIE sucks at W3C's HTML (heaps of missing tags, or not completely implemented ones), XHTML (which it doesn't understand at all in fact), W3C DOM/DOM Events and their binding in ECMA-262 (also known as ECMAScript/Javascript), XSL/XSLT...

Re:User Needs vs Software Perfection

[Anonymous Coward]

And don't even think about their initial CSS stab, the web still suffers from that today.

Practically everybody has dropped Netscape 4 support by now.

Their "initial CSS stab" was a rushed job. They had decided that JSSSL, a stylesheet language based on Javascript, was a better choice than CSS. The W3C decided to adopt CSS rather than JSSSL, and so they had to back-pedal and add support for CSS quickly.

Interestingly enough, one of the big criticisms of JSSSL is that it violated the "Principle of Least Power"; that it provided the full power of a procedural scripting language when only a declarative language was really needed. Of course, once Microsoft had killed Netscape, they added in a bunch of proprietary expression extensions to their implementation of CSS, neatly violating the principle themselves, after nobody could stop them.

But it wasn't the "initial stab" that was such a problem for the web. If Netscape 4 had have been followed up by a timely Netscape 5 instead of the Mozilla people going off and writing a whole fucking platform instead of a browser, then nobody would have really cared, because the Netscape 4 users would have moved on to Netscape 5 fairly quickly, which, presumably would have had decent CSS support.

It's the same problem that we are seeing with Internet Explorer today. It's not the fact that Internet Explorer 6's CSS support is so crappy that is the problem. It 's the fact that once Microsoft killed Netscape, they didn't have to bother with improving Internet Explorer, so they disbanded the development teams and discontinued the software. This means that there was no timely Internet Explorer 7 with improved CSS to upgrade to, and everybody using Internet Explorer is stuck with a version that is four years out of date.

This is one of the reasons why an abusive monopoly is so bad. The moment Firefox started to make serious inroads into the browser market, Microsoft paid attention and reformed the Internet Explorer development team. There will now be an Internet Explorer 7.0 beta for Windows XP at the end of the summer. But in the meantime, and until people upgrade, us web developers will be stuck with "the new Netscape 4" - Internet Explorer 6.

Re:User Needs vs Software Perfection

[Foolomon]

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.)

Re:User Needs vs Software Perfection

[j79]

AFAIK, this did not start with the Acid2 tests. This has been an on going issue with the KDE developers. It was the Acid2 test that pushed them over the limit.

Also, it was not "Apple" that created a build of webcore that passed the test. It was David Hyatt, a software developer, who created the patches so Safari would pass the Acid 2 test. None of the patches have been implemented into Safari yet. He, in fact, stated publicly, that while Safari did pass Acid2, it broke other aspects of Safari. So, I'm willing to bet there is much more work before those patches are included into Webcore.

Secondly, it has not been accusations of Apple not adhering to the standards. Nor was it an issue with Apple's code being "messy" (while KDE developers have stated such-which is one reason they say it makes it harder to decipher a diff file...) The issue at hand is this:

Uninformed Slashdotters, who believe the relationship between Apple and KDE is great. That a partnership was forged when Safari was released and the two work hand in hand.

That is the issue. After the Acid2 test debacle, they had to let the world know that, NO, Apple does not come by after every patch, and say "Hey! Here's the 6MB diff file. Let me explain it to you!", while Apple and KDE developers code into the night, occasionally stopping to play a game of WoW.

Instead, they're sent a huge diff file...and that's pretty much it. So when people (Slashdotters, for instance), start with the "Well, Apple has it?!? Why don't you?" - they should realize it's not KDE's fault. Nor is it Apple's fault. Granted, the relationship is far from perfect. It's OUR fault, for ever believing there was this "perfect" relationship to begin with.

Re:User Needs vs Software Perfection

[StormReaver]

"Software Perfection" isn't the point the KHTML developers were making. They aren't accusing Apple of violating a license (how the hell did that thread get started????).

They are saying that, despite all the media to the contrary, Apple's work is of no use to the KHTML developers. This is because Apple has been providing its changes in huge blobs without providing any clues what those changes are for or how they relate the the rest of the KHTML renderer.

Apple is following the license, which was never in doubt, but is being mean-spirited about it. The KDE devs just want people to stop the nonsensical meme that Apple is somehow helping KHTML development.

As I understand the situation, it is somewhat like an editor of a large book returning to the author only the errors in the book, but without any type of markup or explanation, in no particular order, and in a foreign language the author doesn't know. While the editor was (strictly speaking) doing his job (which is to find the errors in the book), he wasn't being very helpful.

The code could be sorted out, given enough time, but it's just as productive to ignore Apple's changes and do it from scratch.

This has nothing to do with focusing on the needs of the users, and it has nothing to do with software perfection. It is purely an issue of Apple being credited with helping KHTML, when it is doing nothing of the sort.

Oh holy shit

[ErichTheWebGuy]

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!

Re:Oh holy shit

[Trillan]

Well, he started it!!

Seriously, the occasional blow-up like this is probably good in the long run. If a little embarassing to watch now.

Heh...

[Otter]

[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...

Re:Heh...

[John Harrison]

Similarly, the reason Apple selected KHTML as its base was that it was so well written. If the KHTML guys hadn't been so anal about doing things "correctly" Apple might never have used the project in the first place.

In the short term, a hack will get a feature out the door more quickly. In the long term, a pile of hacks doesn't hold up as well as a properly engineered soltution. Notice how some browsers (Netscape, ie) had to be rewritten from scratch a few times.

It seems to me that each project should feel free to proceed as they see fit. Who knows, maybe in the future Apple will come back to KHTML in order to get that stable base again.

Re:Heh...

[Ford Prefect]

It seems to me that each project should feel free to proceed as they see fit. Who knows, maybe in the future Apple will come back to KHTML in order to get that stable base again.

I hope so. I've found bugs in Safari's rendering which aren't in recent Konqueror releases - one I've seen a lot involves CSS-defined borders on table cells creeping out from where they're supposed to be.

Here's a rather nasty example I've plucked from a site I've worked on - excuse the awful HTML!

On Safari 1.3 on MacOS X 10.3.9, there's a green line which extends right along the top of the large month cell at the bottom - this doesn't happen in IE, Firefox or (last time I checked) Konqueror.

It sounds unlikely that Apple's WebCore will ever be 'synced' back to KDE's KHTML, sadly, and they do sound as if they're diverging pretty quickly...

Mutually Exclusive?

[Goo.cc]

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

Are these two things really mutually exclusive?

Re:Mutually Exclusive?

[cowscows]

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.

Is it tortoise and the hare?

[Ckwop]

This is one question I'm really not sure I have the answer to. Is doing it properly better in the long run. The problem with a hacked bug fix is that it stays a hacked bug fix forever. Period.

Evenutally, that hack becomes a trouble to maintain and I'd bet my bottom dollar that it then takes more time to remove the hack and rework it properly that it would have taken to fix it properly in the first place.

I suspect the reason Longhorn is taking so damned long is because this problem is just starting to pinch Microsoft. The "Just get the product out" mentality works for a while - but then all that extra complexity comes back and makes your life very hard.

Simon.

Re:Is it tortoise and the hare?

[mmeister]

Evenutally, that hack becomes a trouble to maintain and I'd bet my bottom dollar that it then takes more time to remove the hack and rework it properly that it would have taken to fix it properly in the first place.

This is always the case with software -- no matter how cleanly you design it, it will degrade over time. To deny this aspect of software development reality is silly

Apple has to maintain WebCore -- so I'm betting "hacking in bug fixes" may be overstated.

Pissing contests

[goldspider]

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!

Re:Pissing contests

[Taladar]

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.

Konq vs FireFox vs world

[B5_geek]

I have always found Konq to be the best alternative to FireFox on sites that are "IE-only". (including my companies intranet.)

As a general web-browser I find Konq to be slow and kludgy, but it has never dissappointed me on the stubborn sites.

Anybody found similar situations?

Re:Konq vs FireFox vs world

[m50d]

I've found the opposite. Konqueror is wonderfully fast (though javascript=treacle) and great as a general browser, however it falls over at even marginally broken javascript and can't handle heavily borked pages as well as firefox.

Odd..

[0x461FAB0BD7D2]

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.

Re:Odd..

[joeslugg]

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

Sorry, but I don't think this is true in all cases. I cite the recent negativity
against Debian and the lack of a recent release. They're now reacting to that
negativity and getting Sarge out the door.

Time to market - while not the ONLY thing - is still important. Whether it's
FOSS or not.

Re:Odd..

[cowscows]

Exactly. Maybe Goodger, (and other people) is wrong in who he's considering as the KHTML team's "target market". Perhaps their primary concern isn't being most used browser in the world. Maybe the end user experience isn't their greatest litmus test.

Maybe the code itself, the creation of a tight, well written, efficient bundle of code is the target. They aren't doing it to fill an opening in the market, they're doing it for the love of the game.

And in the process, they made something that a company as influential as Apple liked. Then Apple used it as a base to follow Goodger's approach, because that's what Apple does. Good for them, and good for the KHTML team for making something so appealing to Apple. If you read some of the rational that Apple gave for choosing KHTML over the mozilla codebase for their browser, it basically boiled down to having a smaller, easier to understand, and easier to modify project.

If I'm right, or at least close to it, in determining the motivation of the KHTML team, it sounds to me like Apple's decision is a solid affirmation that they've been successful. So let Apple do their own thing, let KHTML do their thing, and Goodger should go back to doing his own thing, instead of judging the motivation of a bunch of successful OSS programmers.

No shit Einstein!

[10Ghz]

"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?

That just doesn't sound right

[rsax]

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?

Re:That just doesn't sound right

[Sentry21]

I think what he's getting at is that software perfection is an unattainable goal - software will always be imperfect, as will everything else.

What he means is that they should stop worrying about philosophical arguments and just write a good browser that does things well. I mean, writing 'perfect' code is nice and all, but apparantly, it doesn't really matter. Compare Konqueror's rendering with Safari's - Safari has recently been coded to pass the Acid2 test. How is Konqueror doing in that respect?

So what if the code is ugly? It can be cleaned up later. What good is pretty, well-written code that doesn't do what it's supposed to do properly? What's the point in having a beautifully architectured system that doesn't do the job? It's better than having an ugly one that doesn't do the job, but if you're going to write a web browser, write one that follows standards. Safari has done this with admittedly ugly code in spots. Konqueror has failed to do this, but has done so with nice code.

In the end, it comes down to the right tool for the job, and if you're a web developer trying to use the full features and expected behaviour of CSS and HTML, Konqueror is not that tool, and Safari is (or will be, once those patches are folded into release). Should the Konqueror developers be chastizing Apple for writing bad code? No, it does the job and their code doesn't, so they have no grounds for complaint other than purely philosophical.

Some times a little conflict is good..

[Visceral Monkey]

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).

Re:Some times a little conflict is good..

[ntsucks]

Can some now scold Debian too? Their focus on social and software perfection, while well intended, can be maddening. I am a long time Debian user but I am about ready to dump them (we'll see when/if Sarge is ever released) because I am stuck in the past due to lack of releases. Long live http://www.backports.org/

Software users don't look at a project's source code and say, "Wow, that source code is pretty, I have to use this software!". Users want the latest features and expect a steady flow of updates. Evolving open source projects that have been most successful are those who have banged out a steady stream of updates and enhancements. Users do not want to wait literally years for a big ball of updates. They want a trickle of updates as they become available.

Re:Some times a little conflict is good..

[bhalo05]

Lack of progress in KHTML? The leap from 3.0 to current 3.4 is so big that many people can now use it as their everyday browser, and it works well most of the time already. I now rarely feel the need to use Firefox anymore.

Whatever....

[Anonymous Coward]

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.

He has a point

[ShatteredDream]

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.

Re:He has a point

[cowscows]

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.

Re:He has a point

[As Seen On TV]

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?

Re:KDE should be grateful.

[Anonymous Coward]

Apple went with KHTML instead of Mozilla. Instead of gratitude, the KDE devs are angry that Apple isn't tailoring their patches for them?

First, KDE devs are grateful. Read one of the many linked blog entries about how Safari has done many good things for the project, if you don't believe me.

However, they are angry at something: people like you. Coming here on /. and making a completely backwards post that misrepresents everything they stand for. Sit down and STFU.

Right as in legal, right as in wrong

[UglyMike]

From the article: "...it was within their rights to do what they did, and no one should begrudge them for it..."

Now, while I agree with the first part, I certainly don't with the second! Just because it is legal does not make it right!

While Apple should indeed not 'bend over' and provide beatifull diff patches that seamlessly upgrade KHTML, SOME effort could have been made as thanks for the effort saved in not having to start from scratch. We certainly CAN and DO begrudge them this 'take all you can, give nothing back'- attitude.

Are they within their rights? Sure!
Are they doing the decent thing? Nope ... so we carry a grudge

Re:Right as in legal, right as in wrong

[rdc_uk]

Only a true idiot would bear a grudge against someone/a company for COMPLYING with the terms of the licence they agreed to.

Apple forked the KHTML engine under the GPL, this requires them to publish their source. Which they do. It does NOT require them to "submit" code patches on ANY OTHER FORK (including the main trunk) at any time, at all. So, mostly or totally, they don't.

At some point, some OSS and Mac zealot saw that Apple had chosen to fork an OSS project to kick off their COMMERCIAL project, and had conflated this in their tiny mind into "Ko0lzors; Apple will be writing many updates for KHTML!!!!".

That zealot was a fool. You are the bigger fool for having believed the first fool.

If the KHTML team had wanted anyone who used their source to build something else from it to contribute back into THEIR project any improvements they made, they WOULD HAVE written themselves such a license. And then Apple would very likely never have picked up KHTML.

You can draw the assertion from their choice of license that this was NOT what they wanted or expected.

In fact if you read the actual KHTML developer blogs, youd find that they don't really CARE that Apple does their own thing and kust posts the output. They DO CARE that people give them grief for being "lazy" for not having done "simple merges" on code that calls a whole bunch of OSX api functions; that aren't available for them to call in the first place.

In summary; you are an ignoramus.

Re:Right as in legal, right as in wrong

[Brian Blessed]

It seems to me that there is a large contingent (possibly US-based?) on this site that thinks that the behaviour of people and organizations should be based on what is legal, satisfying merely the bare-minimum requirements.

I think that Apple should clearly not only comply with the law of the GPL, but also the spirit. According to the reports, they are sending huge patches that combine many fixes without any documentation. There is no way that the KHTML people will be able to use these, so the work will ultimately have to be duplicated. The questions on here should be asking: why are Apple behaving in such an anti-social way given that they stand to benefit from helping the KHTML developers?

- Brian.

MoFo getting more like MS by the day, it seems

[McDutchie]

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.

Re:KDE should be grateful.

[10Ghz]

Apple went with KHTML instead of Mozilla. Instead of gratitude, the KDE devs are angry that Apple isn't tailoring their patches for them?

KDE-guys did not complain about Apple as such. They even specificly mentioned that Apple is abiding by the license. what they complained about were the USERS who whined when KHTML took time to incorporate improvements made in WebCore!

Do you "get it" now, or do I have to hit you with a clue-by-four?

Re:Boy are you dumb

[BladeMelbourne]

Safari only passed the Acid 2 Test because the developer David Hyatt spent time over two weeks to make it pass.

I'm not saying that this is a bad thing, in fact it's an excellent thing. But the fact is Safari, Mozilla and MSIE all failed the Acid 2 test when it was released. Using MSIE I see red. lol.

Now Safari passes. And no doubt each would fail several more tough tests. No one test can prove a superior rendering engine, unless it was 10 MB big and tested every [X]HTML/CSS1,2,3/JavaScript specification in various scenarios.

I'm looking foward to getting a Mac Mini and seing how good Safari is. It will also allow me to develop web pages against Safari for the first time.

From TFA

[ooze]

"The gulf between the people making software and the people using it is widening,"

Now, the reason for that is basically that more and more users with no idea of computers are able to use it and use it. So it's not a sign of a Software designer failure but a sign that Software designers are doing "The Right Thing" TM and successfully so.

So the following quote

"Over time, software has come to demand an impossibly high level of computer literacy" is basically wrong. Just compare it to the times when the interface was binary machine code.

The base intetion of the article I agree with though...the Safari Engine is much mure advanced than KHTML, due to more pragmatism in development.

As long as you build software on operating systems who still are stuck in the concepts developed 30 years ago, you have to be pragmatic. Basically implementing anything there is a workaround.

Safari and KHTML

[danalien]

Safari and KHTML
Submitted by carewolf on Fri, 05/13/2005 - 10:33.

• 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.

Safari and KHTML again
Submitted by carewolf on Sat, 04/30/2005 - 13:22.

• 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.

Emphasis added by me...

Re:Safari and KHTML

[JulianOolian]

We are doing this for free and for fun, all we really want is appreciation for our effort.

So are they doing it for fun, or because they want appreciation for their effort?

Re:KDE should be grateful.

[10Ghz]

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.

Considering that this thing has been discussed quite a bit recently, I would have guessed that by now everyone who is interested on this would have read the ORIGINAL messages that sparked this whole thing? I mean this message

Re:Boy are you dumb

[nine-times]

Safari only passed the Acid 2 Test because the developer David Hyatt spent time over two weeks to make it pass.

Wasn't that the purpose of the Acid 2 test? To give an example of common rendering problems so that browser developers could see what their browser was doing wrong? Now, I'm not saying that passing the Acid2 test means the rendering is perfect, but the challenge was placed out there, and the Safari developers took it up. It's exactly what Mozilla and MS and KDE should do, too.

Now, if after all that, we can come up with a new series of serious rendering errors not addressed by the Acid2 test, then let's make an Acid3 test, or whatever. But I don't see the grounds for complaint. It's like saying, "well the only reason Firefox renders HTML properly is because the Mozilla team spent time to make it render HTML properly." Well, good. That's what they should be doing.

Where "free" software fails

[putaro]

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.

Re:KDE should be grateful.

[telbij]

Considering that this thing has been discussed quite a bit recently, I would have guessed that by now everyone who is interested on this would have read the ORIGINAL messages that sparked this whole thing? I mean this message

Incidentally, no I hadn't read that. I really don't see how all the linked articles follow from that (completely reasonable post). Must be a hugely escalated flamewar which I had no business getting involved in. I apologize.

Re:right....

[Anonymous Coward]

No...he gave them the KFinger :)

Don't Follow Firefox Adivce: considered Bad!

[kupci]

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.

Re:Don't Follow Firefox Adivce: considered Bad!

[jalefkowit]

Now finally the wisdom of that choice has come to fruition.

The "wisdom" of that choice has forced them to rebuild market share from scratch -- from 0% -- because the 60-some percent of people who were using Netscape when they started had completely bled away by the time they were done.

Don't get me wrong, I loooove what Firefox has become. But I would hardly point to the early management decisions of the Mozilla Project as a shining example of the Right Way to do software.

Re:??? HUH ???

[rpdillon]

While your article is fascinating, looking backwards to find all your solutions is hardly insightful.

Martin Fowler has tremendous insight, which is not to say we should swallow Agile Development or XP whole, but rather look to the New Methodology for ways to improve.

Your article mentions looking to government and large corporations for the answers about the Right way to program. I suppose it refers to someone like Microsoft, who has no real notion of unit testing in their software development process?

This isn't meant to be a dig against your article or old methods; it is meant to be a dig against those who would hide behind a shield of contempt for the "latest buzzwords" to avoid change.

I praise any organization that looks for the Right Way to design and write their software, because it takes courage, and in the long run, that software will become an asset intead of a liability. I think the methods espoused in The New Methodology/Agile Programming have a lot to offer us as we refine our methods to create The Right Way, and is time very well spent.

This is an old story

[slickrockpete]

It reminds me of the conflict between Lucid and Stallman over emacs.

Lucid had a product to get out, Stallman wanted to do everything right and his way. It resulted in the emacs/Xeamcs schism. I didn't work on this directly, but saw my coworkers dealing with this as it happened. My view of the whole thing certainly biased by my experience there. Regardless, it wasn't pretty.

Wherever there are multiple development teams this tension between the ones that want to get the product out now, and the ones that want to do "the right thing" will exist. I personally think the tension is good. You should strive to do the right thing, but when it comes right down to it you need to produce something people can use in a timely manner.

I just hope this doesn't produce another schism.

Re:KDE should be grateful.

[pohl]

Whoa, that's out-of-bounds, dude. How are we going to keep up this pan-fora flamewar if people go around apologizing and admitting that the other side was reasonable!? If you don't have something destructive to say, don't say anything at all.

It's a matter of Tone

[psychopracter]

There's a reason "team KDE" is taking some lumps despite the fact that yes, the text says that he's angry about people who accuse his team of being lazy, etc because Safari code is not instantly merged into KDE.

Its because the tone of his comments make it clear that he's plenty pissed at Apple. The tone is one of "So there!" Which is why so many people have percieved this as a slap against Apple, and not ignorant end users.

Had he said something more neutral in tone like, "The roots of the problem lie in the fact Safari is now forked in a different direction than KHTML, Apple's inhouse code isn't the cleanest, their commenting isn't detailed, several features rely on things specific to OS X, and they drop us massive 'code bombs'. This means that it takes time to pick through the code and see what works with KHTML. They zigged, we zagged, and don't assume we're working closely because we're not in eachother's backpockets." we probably would not have this kerfluffle at all.

"Pobody's Nurfect" and all, but when you've got a spotlight on you as a project heavy, you've got to watch tone and content of posts.

Re: Do have to admit though........

[SirTalon42]

KDE has a page (http://www.kde.org/info/requirements/3.4.php) listing all of their requirements, I'll provide you all the things marked as 'required'

QT
X Server
Perl
BZip2
ZLib
PCRE
LibPNG

There are other things marked as recommended (such as OpenGL and OGG Vorbis), and there are others marked as optional (such as LAME).

The problem isn't KDE is bloated, its the way the distros package it (huge monolithic packages that contain a load of different programs), though some distros like Gentoo now provide 1 package per app (which allows you to trim most packages off.

Also comparing KDE to XFCE makes no sense, XFCE is an extremely minimalistic desktop environment (its just a bit more than only a Window Manager). Only comparing KDE to GNOME would make any sense since both are complete desktop environments.

Tests are no substitute for good design

[expro]

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.

Re:Tests are no substitute for good design

[Matje]

If you're still inclined, take a look at "Agile software development" by Cockburn. He's not telling you to abandon all design. Instead, he claims that you should not perform any 'overhead' activity if it isn't needed to get the job done. So if the complexity of your project requires you to plan a design phase, by all means do. But, if you're in a project where you can go ahead succesfully without performing an initial design phase, then don't! It's as simple as that, really.

Re:Tests are no substitute for good design

[SlowMovingTarget]

Unit tests (written with frameworks like JUnit or TestNG) are intended to require a perspective shift of the developer writing the code. Specifically, the developer must think like a client programmer for whatever module they are testing. As such, these kinds of tests are design aids, not design replacements. In fact, they are advocated not for their ability to verify requirements, but rather, for their ability make design improvement less risky.

Naturally, accepting this requires a reasonable adjustment in thinking. If you ask yourself what the design of a software module actually is, the answer you arrive at is "the design is the code." After all, the code is a written specification of what the software should do when it actually executes.

Most agile methodologies do not ask you to abandon the principles of adequate forward-looking design. Rather, they ask you to abandon the assumption that all forward-looking design is adequate. This faces up to the hard fact that diagrams drawn in a tool rarely resemble the actual implementation in code, even if the implementation stays true to the spirit of these drawings.

And for the record, Extreme Programming is not the only agile method, nor is it the gold standard for agility.

Re:Tests are no substitute for good design

[h4rm0ny]

In other words - carry on the way you were. Is it really such a revolution to say "don't do unnecessary work?"

Why, thank you! I'd never thought of that. If you're "in a project where you can go ahead successfully without performing an initial design phase," then you're probably working on Hello World.

Really, the secret is hire good people to do the job, set realistic deadlines but enforce them, block /. at your company firewall.

The XP "methodology" works for evolving things like GUIs and little else.

So let's get this straight:

[Dasher42]

Apple's Webcore is a major revision of KHTML to support OS-X features and Objective C to work with Apple's standalone browser.

Firefox is a cross-platform standalone browser.

KDE is a complete desktop environment and programming framework that builds its components to integrate well with each other; KHTML and underlies the working of a great many programs, and Konqueror is not just a web browser.

KHTML programmers, pay no attention to this mindless brouhaha. The overall integration and design sense of KDE is a bigger strength than any minor perk of either Safari or Firefox. When you get there, you will have more than the sum of your features.

- A very satisfied user of KDE

Re: Do have to admit though........

[KingBahamut]

Goes back to nessecity. What do you as a person need? I can easily compare Xfce to Kde in my own right, and say yep, its faster and more stable. It DOES WHAT I NEED it to do. You may say otherwise , and again as previously stated by me, that is your right. Xfce doesnt do what you want it to do for you, thats fine. But you cannot discredit a DE based on its minimalist stature. KDE and Gnome applications run fine in Xfce for me, and properly configured, it too can be as complete and featurefull as KDE or Gnome can be. Goes back again to nessecity , what do you need to have to make your desktop viable? Are you afraid to configure things on your own? Do you want KDE to supply you with an out of the box solution, that requires you to configure things minimally , if for no other reason than look and feel? For Joe User this might be viable. But if your a seasoned linux user , and you still are too lazy to set things up properly, using the atrophical statement of "KDE does it all for me, why should I have to?" , then thats your loss. Laziness over Desire, in this case.

Re:??? HUH ???

[saider]

Both of those approaches have points of value, but they are both extremes. The Agile way seems to be more appropriate for contracts for time, whereas the "Fragile" approach is more applicable to fixed price contracts.

Agile works as long as the customer is willing to pay for the changes. Agile is good because the customer sees progress. Agile is bad because an indecisive customer can flip-flop on features and cause significant headaches.

Fragile works better where the customer needs a specific solution. They list their demands and your company realizes those demands for a price. Changes are discouraged, but that should be fine as long as the customer knows exactly what they want. The company's process ensures that what is contracted for is met. This is not good for research type projects, where the best solution is not known and needs some experimentation.

Note: One would have trouble applying the Agile paradigm to any kind of regulatory environment. Telecom, medical, and military/government contracts pretty much mandate the use of the "Fragile" system.

Pursuing Software Perfection is a GOOD THING...

[rben]

But a big part of that is supplying what the users need. I think all three sides of this discussion could learn a thing or two by listening to the others.

You don't get involved in an open source project to write crappy code. You get involved in order to fix a problem that bugs you, show off your coding skills, or do a little good for the community. One of the benefits of coding for open source is that you really can take the time to get it right.

Businesses often fail to pursue excellence in coding because they believe that by taking shortcuts they save money. That's almost always wrong. One of the reasons that Netscape got beat by IE was (and I know I'll get beaten for saying this) that IE was written in a modular way that allowed it to be used more flexibly than Netscape. The IE code was better planned and executed. The developers who joined the Mozilla project took the original Netscape code and hammered on it for a long time to produce the successful browser that we now have. Even so, it was bloated and in need of a lot of trimming. So the Firefox project fixed those problems and now Netscape is based on the Firefox core rather than the original Mozilla core. (Sharing is a good thing.)

Apparently Apple believes that by taking short cuts they save money because the FOSS community will come in behind their engineers and clean up the code for them the way they did for Netscape. Why shouldn't Apple take advantage of the same mechanism?

What happens too often in corporations and is apparently happening in this part of Apple, is that they have forgotten that they are dealing with people. The FOSS crowd seems to have more than it's fair share of idealists, and they dont' like being taken advantage of. Hopefully Apple has figured this out by now and is working on a plan to mend fences. Otherwise it might be very hard for them to get help from the community in the future. It would be a shame for OS/X to fail because of foolish management mistakes on the Safari side.

Open Source can learn a lot from what Appled did, though, even if we don't like how it turned out. Appled focused on fixing things that were causing problems for their customers. They also focused on becoming standards compliant. A lot of FOSS projects come up short in that area. What gets attention is whatever is cool to code or bugging a particular developer. Not enough of the FOSS projects have any real central focus.

Listen, learn, and move on. The best thing that could come out of this whole mess is a good discussion on how FOSS and regular software companies can work together to mutual benefit. Perhaps we need some kind of template agreement that makes responsibilities clear so that the companies involved don't make bad assumptions like the ones Apple seems to have made.

Apple offered, but KHTML didn't want to.

[Paradox]

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.

No user satisfaction without software perfection

[mi]

[...] instead of insisting on software perfection.

Firefox is doomed if its "lead developer" thinks, users can be satisfied without software perfection.

Thanks to this perfection, KDE builds and runs, while Mozilla/Firefox can fall over when you pick wrong compiler flags -- especially on "exotic" platforms like FreeBSD/amd64.

The amount of compiler warnings in Mozilla code is astounding. Quite clearly it was written by result-oriented professional engineers, rather than the process-enjoying hobbyists.

Mr. Sarcasm says...

[craXORjack]

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

But if we hadn't waited on software perfection, we wouldn't all be playing Duke Nukem Forever on top of the GNU Hurd.

What many fail to realize...

[Agram]

...is that while Apple is not required to do anything for KHTML developers, other than what they already did, the issue is more associated with the sense of OSS etiquette, or "developer-courtesy" if you like, and this is where Apple is at fault. Allow me to explain:

Apple got a very clean codebase from the KHTML developers which they managed to deploy rather rapidly and thus we got Safari, which ultimately helped Apple to move away from Apple version of IE (which, as we all know already, is abysmal version of an already less-than-adequate browser). Apple has clearly profitted from this move.

In return, they have provided patches in order to keep compliant with the LGPL license, but they have done so in much less "courteous" way than what they got from KHTML developers (perhaps buggy, but nonetheless clean code). And this is where the problem starts, especially considering that Apple is a for-profit company. The least they could do is provide such patches in a fashion that all other KHTML developers/contributors adhere to. Why should they be above the etiquette established by the project, especially when they have clearly profitted from this collaboration, while KHTML people have not nearly as much.

And for those of you, especially Mr. Goodger, who as a lead engineer has very likely had his share of patching experiences, who claim that KHTML developers should go ahead and patch the whole project with the bundled superpatch from Apple, perhaps you should try to do that on your own just to realize how much overhead such patching introduces when it comes to debugging and clean-up.

This is why most of above-average programmers will rather not use such patches at all and make comparable fixes from scratch.

So, in short, Apple has not done anything wrong legally, but they surely did prove that they are just another corporation that cares about self-gratification, but then again, is anyone surprised?

Expanding on parent a bit

[baadger]

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

Opera.. [Yes damnit I'm mentioning Opera to be made an example of in an Apple-KHTML-Firefox related article so mod me offtopic if you must] manages a smooth, sexy well refined, suite with distinct lack of clumsiness, a fast and obviously efficient backend, with excellent standards compliance and features. You can almost taste the oodles of care put in to perfecting the product for the 'users needs'.

IMHO 'software perfection' in terms of a smooth and stress free user experience (and I don't mean just the UI - Opera particuarly has never, for me personally, crashed or blown bugs at me with 12 months of use) is waaaaaay more important than 100% compliance to standards or sitting on the cutting edge of the blade.

Firefox almost makes up for it's clumsy floppering about (which i'd rather not digress into and start a flame) with it's feature set. But, for me, and MLHO, not quite.

The "needs of the users" in the way meant in the entry, for example a better renderer, don't come into the equation much in terms of 'perfection' here.
You can enter one discussion and everyone says ~"Use firefox, it's more secure!", then someone pipes up that logically, and quite rightly, it is not (again let's not digress into that debate). Then everyone says ~"But firefox has tabbed browsing and standards compliance and all these neat extensions!". The fact is the geekdom minority pushed, and is still pushing, the majority to use something most people simply don't care much about. IMHO the 'average Joe' primarily wants a program that won't crash, slow down, or exhibit visible or annoying bugs.

Most of my friends I admitedly pushed into using Firefox still use the default theme and 0 extensions, some even use windows (note the little w :P) but they still like to bitch like hell when it flumps after opening X tabs (although none have defaulted back to IE)

Obviously you need a balance of the latest whizzy gizmo compatibility and careful implementation, but being a bit of a perfectionist myself I would urge the KDE team to stick their nose up and get on with what it is they are doing. I wouldn't let a minority of people push them about. There is nothing wrong with being a perfectionist, even if you are seemingly 'wasting' time or a bit behind the 'competition'. Good for you KDE.

This sounds so reasonable

[FredFnord]

I hear this, and my first impulse is really to agree.

But I do have to sit back and think about what you're really saying. Which is, "Okay, Apple, here is our source code. And here is the way everything should be done."

I've cooperated with other companies enough to know that, when there is a clash of corporate culture, it is very rarely just one side that is to blame. It is generally either both or neither.

Sometimes the two companies are just two different in philosophy to cooperate smoothly. That's no one's fault, but when it happens, there are two choices: either deal with the unpleasantness at the interface, or stop. Yelling about it is a waste of everyone's time, and yelling 'We're right! We're right and they're wrong!' is a good way to get premature age lines and dyspepsia. And not a whole lot else.

Including popularity.

-fred

Re:This sounds so reasonable

[JohnFluxx]

Actually Apple is now encouraging some of their engineers to come and talk to us more now. We have spent many hours discussing things back and forth, and hope is high on both sides for a better relationship.

So, I guess in this case, the squeaky wheel gets the grease :)