Firefox Lead Engineer Scolds KDE Project 669
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."
Agile (Score:3, Insightful)
Can't wait... (Score:3, Insightful)
Personally I can't wait for the KDE response which scolds the Firefox developers for having such huge and stupid security holes in their browser.
Maybe the Firefox team should get rid of the glass walls before they start chucking stones at other people.
In a way I agree (Score:5, Insightful)
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.
Blah... (Score:2, Insightful)
Uh.. (Score:4, Insightful)
Can't we figure out what the users need, and then deliver excellently written software to do that?
User Needs vs Software Perfection (Score:4, Insightful)
Now I think back to 1995, when IE focused on user needs over software perfection and the following of published specifications. And look what a mess of incompatibility we have today of javascript, css, java VMs, etc. Mainly because M$ focused on 'the needs of users.' No thanks, I'll stick to the specs.
Oh holy shit (Score:5, Insightful)
Re:Uh.. (Score:3, Insightful)
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.
Heh... (Score:5, Insightful)
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:Blah... (Score:5, Insightful)
Boy are you dumb (Score:0, Insightful)
Is it tortoise and the hare? (Score:3, Insightful)
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:Uh.. (Score:5, Insightful)
It can be developed quickly, cheaply, or correctly (but you may only pick two of the three options)
Re:User Needs vs Software Perfection (Score:5, Insightful)
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
Pissing contests (Score:5, Insightful)
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:Uh.. (Score:4, Insightful)
Re:User Needs vs Software Perfection (Score:5, Insightful)
Odd.. (Score:5, Insightful)
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:Blah... (Score:5, Insightful)
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:User Needs vs Software Perfection (Score:2, Insightful)
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.
No shit Einstein! (Score:5, Insightful)
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 (Score:5, Insightful)
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?
Some times a little conflict is good.. (Score:4, Insightful)
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:In a way I agree (Score:3, Insightful)
Ok, so that sounds like IE's early days. I say "early days" because its flaws are nothing less than eyepopping these days. Anyway, I don't care how well Safari works and how good or bad it is or isn't behind the scenes. What I care for is that Konqueror is very well written, very stable and very fast. I use Konqueror (for browsing) about as much as Firefox, maybe more. I really think the Konqueror guys deserve every bit of appreciation for their long great work. I wouldn't like KHTML being dropped in favour of an engine hacked together by Apple devs.
He has a point (Score:5, Insightful)
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.
Right as in legal, right as in wrong (Score:2, Insightful)
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
MoFo getting more like MS by the day, it seems (Score:5, Insightful)
From TFA:
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.
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?
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:User Needs vs Software Perfection (Score:4, Insightful)
Safari's code is capable of performing to publish specifications.
Microsoft's objective was to create their own specification.
Entirely different thinking.
Comment removed (Score:5, Insightful)
What? The community doesn't have a single mind?? (Score:1, Insightful)
This guy is obviously a fraud, everybody on Slashdot knows that everyone that supports open source has the same opinions on anything surrounds software.
Mod that blog down!
Ok, seriously, it's humorous how often you see crap like "The community says this" or the "The community thinks that". "The community is just ungrateful", etc. Can Microsoft lackeys shut up already with this crap?
Re:Blah... (Score:5, Insightful)
Re:Blah... (Score:5, Insightful)
And now _we_ are the pain to work with and aren't encouraging participation??
Re:Can't wait... (Score:1, Insightful)
The only troll here is the Firefox developer.
Slashdot: where the truth gets buried under the moderation system
Re:Uh.. (Score:1, Insightful)
Sounds like Microsoft. Sounds like the kind of approach that can lead to the bloated code that Netscape was famous for.
I'm glad that we have multiple competing FOSS projects. The best test of who's right is to do both, and see who ends up with the best result. As opposed to primitive chest thumping "do it my way" monotheistic nonsense, as epitomized by Ben Goodger's little hissy fit.
Re:Can't wait... (Score:2, Insightful)
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:Pissing contests (Score:5, Insightful)
Where "free" software fails (Score:5, Insightful)
Re:Blah... (Score:5, Insightful)
Re:In a way I agree (Score:5, Insightful)
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:Can't wait... (Score:3, Insightful)
Re:Blah... (Score:5, Insightful)
These attributes naturally go away as you add functionality to any code. That is a fact of software development.
Re:In a way I agree (Score:1, Insightful)
Re:Right as in legal, right as in wrong (Score:3, Insightful)
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 (Score:3, Insightful)
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.
Re:Is it tortoise and the hare? (Score:2, Insightful)
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.
Re:He has a point (Score:4, Insightful)
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:In a way I agree (Score:2, Insightful)
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.
Don't Follow Firefox Adivce: considered Bad! (Score:3, Insightful)
Re:In a way I agree (Score:5, Insightful)
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:Odd.. (Score:3, Insightful)
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.
Re:In a way I agree (Score:1, Insightful)
Says you? Just look at all the blogs and postings about it. This isn't a recent thing, it's been going on since the beginning.
"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."
No - they're purposfully difficult to integrate back into KHTML. The apple patches don't include changelogs, they have too many references to closed-source apple API's and modified QT API's.. they'd fix bugs without consideration on other things it would break (some of which would be things apple didn't use so they simply didn't care.)
"I think there is a bit of arrogance on the KHTML side to not even consider the aspect of WebCore."
Which aspect? And why arrogant? The KDE devs WROTE the damned thing. It's their baby. They're not going to ditch their project for some bastard-child that Apple has created.
"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."
Bullshit! Think about: You're a principal developer in designing a strong HTML renderer. You put a lot of time and effort into it. 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.
This is all perfectly legal and proper in the GPL, and nobody is saying it's not. But it does go against the spirit of Free Software - and against the new Apple Mantra of "OSX is great. Apple is great. They work with OSS and take the best of both worlds. We love OSX. Apple is great."
"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."
Apple isn't just "offering up" changes. They are required to do so by law. While they've made improvements, to say "they can't easily be patched" is an understatement. Using WebCore for a basis of new KHTML is a joke because you'd basically have to port it from an OSX only app to a platform independant one. Who, in their right mind, would want to do that?
Re:User Needs vs Software Perfection (Score:3, Insightful)
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:Uh.. (Score:5, Insightful)
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:Mutually Exclusive? (Score:4, Insightful)
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.
Re:Can't wait... (Score:3, Insightful)
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:??? HUH ??? (Score:3, 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.
Re:Blah... (Score:0, Insightful)
Look around you
Re:That just doesn't sound right (Score:3, Insightful)
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.
Re:Can't wait... (Score:2, Insightful)
You did not read his blog entry, did you?
Re:Odd.. (Score:1, Insightful)
Tests are no substitute for good design (Score:5, Insightful)
I am sure to be modded OT as this whole thread is, but...
The Agile/XP movement is warped at best. Tests are no substitute for good design and they cannot prove any useful level conformance to a design (except in an extremely trivial application). Tests are useful in many cases, unless they are used to rationalize bad practices based on false notions.
And the more extremists you have trying to force it to be so, the worse the XP/Agile movement is percieved. Sure, they picked up on parts of a number of good practices that good programmers already followed, but when will they stop twisting them and advocating that experienced programmers abandon principles of adequate forward-looking design and methodology and follow the way which is what they ultimately believe to be The Only Right Extreme Way.
They resemble the pointy-haired managers who would like to think they can substitute their process for masterful programming and design.
I was attracted to XP by their advocacy of some of the more-reasonable principles until the fanatics showed why it was really called extreme programming. They need apologists to start really apologizing.
Re:Agile (Score:1, Insightful)
Users don't want a trickle of new features every few weeks. Either they'll get annoyed by the constant upgrading, or they'll just choose to stay where they are and ignore your releases.
The "release often" mentality is another classic case of programmers writing for other programmers, not for actual human beings.
And your "the customer gets pissy" thing is no excuse. You can't solve a failure to understand the customer's requirements by employing a user-hostile release model.
Re:In a way I agree (Score:4, Insightful)
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.
So they should stop making software... (Score:2, Insightful)
and let hardware sell itself, yea, sure.
I do not believe your 4% interpretation exhibits a clue about their focus and efforts on software or the value of the software to those purchasing the hardware.
And you are trying to claim that they got by on 3 million in total net sales last year?
Not likely.
So let's get this straight: (Score:2, Insightful)
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........ (Score:2, Insightful)
Re:In a way I agree (Score:2, Insightful)
KDE is somewhat more portable then OSX, even still.
The goal of KHTML was never to provide the world with a free rendering engine, it was to provide a rendering engine that will work well for their project. They wrote it so it could run on a variety of hardware. Obviously their work in this regard paid off, because Apple was able to take KHTML and integrate it into a completely non-KDE app without much rewriting (most of their initial work was done to improve rendering functions.)
Really, Apple could have been a big contributer to the KHTML project. If they worked with the KDE project team and/or offered to help lead the project - not as an Apple centric project but a KHTML project - things would have been better for everyone. But, they're a corporation, and this is what can happen. Now, Apple will have to maintain an entire browser project moving forward, without any outside assistance.
There's weaknesses in OSS development models and Corporate ones. We're all human. But corporations just tend to be a little bit more cut-throat.
In the end, OSS does work and I don't think this will actually hurt KDE at all. If Apple never came around it wouldn't have made any difference. The KDE project exists to provide a nice desktop environment to free systems, not to compete in the top 10 browser war.
Apple offered, but KHTML didn't want to. (Score:5, Insightful)
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.
Re:Tests are no substitute for good design (Score:3, Insightful)
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:Uh.. (Score:3, Insightful)
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.
Re:In a way I agree (Score:5, Insightful)
Ok, so that sounds like IE's early days. I say "early days" because its flaws are nothing less than eyepopping these days. Anyway, I don't care how well Safari works and how good or bad it is or isn't behind the scenes. What I care for is that Konqueror is very well written, very stable and very fast. I use Konqueror (for browsing) about as much as Firefox, maybe more. I really think the Konqueror guys deserve every bit of appreciation for their long great work. I wouldn't like KHTML being dropped in favour of an engine hacked together by Apple devs.
I think you're missing the bigger point here....
Yes, KHTML is "well written, very stable and very fast". But so is WebCore, which is obviously derived from the same KHTML tree that you care for so deeply... but WebCore is vastly more capable. Sure, the KHTML guys deserve recoginition for their work, but to characterize Apple's fork as "hacked together" is a gross misunderstanding. The WebCore engine is clearly the superior technology and Apple's developers are clearly responsible for the progression that WebCore has made over KHTML.
The reality here is that this whole mess is nothing more than KHTML's developers wanting to have their cake and eat it to. They welcomed Apple to the table with the hopes of some full time developers helping out with KHTML, but then poo-poo'd Apple's efforts when they realised that Apple was foolishly committed to solving problems for their customers, rather then just writing pretty code.
This is one of those problems that happens time and time agian with open source projects - the developers become so consumed by making a technically superior product that they forget to deal with the fact that it's functionally underwhelming. There are a choice few exceptions to this rule... great sucess stories no doubt (Linux and Apache come to mind)... but they are certainly the exception, not the rule. Case in point... the Gimp. If I hear one more zealot even try to compare it to Photoshop.... No doubt, the code to the Gimp is probably cleaner,better written, and less prone to memory leaks.... but it doesn't change the fact that Photoshop is light years more advanced (4 letters: CMYK) and a lot more elegent to use.
Of course, what really bothers me is when these inadequecies are overlooked by zealots who disregard ease-of-use and functional elegence because they appreciate the idealogy of the developers. What kind of brain-dead reasoning is that? If "poorly" designed code -works better- for the end user, than it's not so poor afterall. This is the key point the KHTML people have missed.
At the end of the day... If the Konq guys absorbed Apple's changes, rather than crying about them, you certaintly wouldn't be complaining that suddenly Konq was a whole lot better than it was -before- Apple got involved, now would you?
Re:Agile (Score:5, Insightful)
Direct software sales may only be 4%, but software is a much larger part of their business than just the revenue percentages indicate.
What many fail to realize... (Score:2, Insightful)
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 (Score:3, Insightful)
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
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.
Re:Blah... (Score:4, Insightful)
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.
Re:Tests are no substitute for good design (Score:3, Insightful)
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
The XP "methodology" works for evolving things like GUIs and little else.
Re:He has a point (Score:5, Insightful)
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:In a way I agree (Score:3, Insightful)
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.
This sounds so reasonable (Score:3, Insightful)
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