Slashdot Mirror
When Volunteer And Commercial Developers Don't Mesh
An "Anonymous" but easily identifiable
person submitted a commercial about a story at LinuxPlanet about
what happens when Volunteers and Commercial Developers have different goals over what is good for the Linux Community.unity and how it
might affect code. The article is largely about KDE and Corel. Please keep the flame turned down on this one, as it's a critical issue that still hasn't been solved.
YES, KDE developers are very grateful for Corel's input ! :-)
I can even prove it : I've digged up the best cvs comment about that: look at this one and this one.
The truth is not always well written in a nice article linked from Slashdot, it's sometimes hidden in CVS logs
If you think you don't need functional abstraction, then the system you use has been so successful you're ignorant of its real complexity.
Linux could still be a lot easier to use, especially if it want to be on normal desktops. Microsoft, whatever its failings, has implemented a lot of good interface ideas in Windows. Using them will make it easier for users to switch away from Windows. (You know, embrace, extend...)
If a commercial venture like Corel can get Linux onto lots of desktops then it's a win for the open source movement. It may have to hijack KDE to do so, but would it really be a loss? Isn't the real goal of the KDE project to "dumb down" Linux anyway?
I bragged about my Karma at a job interview but I didn't get the job.
Of course they are. This is nothing new; it's implicit in ESR's Bazaar model of open software development. The conflicts under discusssion right now are with corporate interests, but if every corporation on Earth went dark it wouldn't change anything because conflict is the heart and soul of creative collaboration.
The tug of war between conflicting interests is what makes for careful scrutiny, the "many eyes" that we're so proud of. Attempts to resolve conflicts are often the seed of brilliant innovations which make previous trade-offs moot.
By all means suspect Corel's UI suggestions, but keep in mind that many of them (such as deprecating inconsistent dialog button labels) are derived from very sound UI principles. We will need to provide Win-flavored UIs as learning aids, if nothing else; if this is anathema to the purists (perhaps including myself) then let's find a way to gracefully theme the problem away.
Peace and harmony are BOR-ING!
Lacking <sarcasm> tags,
This was bound to happen some time. There is an inherent conflict within every linux lover - they want to see it succeed commercially but they don't wan't it to go commercial. Till the linux community resolves this within itself (like by defining a core that is open source and let the rest be a commercial playground), there can be no real commercial progress that can satisfy both the communities.
Experience would suggest that anyone, whether corporate or individual, who gets involved with a project and makes suggestions; if that person/individual makes good suggestions and especially offer to implement them they'll be accepted. But if they are not particularly good suggestions they won't. Free software projects don't tend to accept patches if they are a hack just to solve some pressing corporate strategy.
Now Corel or whoever can go ahead and fork either the entire KDE or individual applications inside KDE. And the user community will either accept it or not. Most probably they won't because corporate maintained software doesn't tend to get maintained. So any sensible company should be desperately wanting to show a bit of diplomacy and get their changes integrated into the main project.
Of course there are bound to be conflicts when the commercial and open source worlds come into conflict. And it's going to happen a hell of a lot more as Linux becomes a more viable platform for corporate ventures. And, as a professional IT consultant, let me tell you that more and more companies, even some of the more staid ones, are becoming more and more interested in getting a piece of the open source pie.
The fact is that large corporations like what they see when they look at open source software - a lack of restrictive and expensive licenses, generally stable software and the kudos that comes from running this kind of solution. But what they don't like is the anarchic, socialist and often anti-corporate views held by the people that write and promote this software.
So their solution? "Collaboration" in open source projects, a method that allows them to "guide" the project in the direction they want - a marketable product. Unfortunately, whilst Linux hackers are quite willing to accept corporate backing when they need to pay the bills, at the slightest hint of a request for a change they immeadiately turn around and bite the hand that feeds them, as this whole KDE-Coral incident has shown.
In the long run it seems as though this dichotomy is going to force conflicts again and again, as commercial interests come up against the socialist ideologies of hackers. The only method I can see for this to change is for open source projects to incorporate themselves, allowing them to become their own masters.
If the KDE developers don't want to use the suggestions Corel gives it, they don't have to.
To be honest, I'd say the guy has a lot of valid points. And if he's been doing UI design for a while, I'd say he could probably bring a lot to KDE.
Contrary to popular belief, UIs are NOT easy to design so that they are intuitive for average users. The KDE team is working on it, I'm sure, but it can't hurt to have somebody help out. Christ, I'm sure there are some OSS projects that would DIE to have a professional UI guy helping out, especially one paid for by a major corporation. But instead of showing some gratitude, they write an article about how Corel might be subverting the KDE project.
To be honest, EVERY SINGLE PERSON who works on KDE is subverting it, in a sense. They are working on it because they want it to work in a way that will please THEM. Corel is no different than your average KDE developer. They want certain features, and they're going to try to get them done.
If they'd wanted to, they could've just started uploading changes to CVS, but they didn't. They filed reports about them, and gave the community the chance to discuss them. And to be honest, I agree with most of the ones listed in this article as being 'bad'. They make sense, especially considering Corel wants KDE to be ready for normal users.
Anyways, just thoughts.
-[Blaine]- "'Oh dear,' says God, 'I hadn't thought of that,' and promptly vanishes in a puff of logic."
I am not qualified to assess whether Corel is a creeping black cancre on open source, BUT... being a profssional tester I am regrettably over-qualified to address the tone of hostility the author assumes towards testing. He writes in part:
"Changing file types is an advanced feature, and it should not be so easily accessible from a right-click menu," said one, on June 9. "A new user could easily handicap his or her system by accidentally playing around with settings without a clear understanding of their purpose." A bug? What here isn't working as designed? Or a dumbing down of KDE? Is there a single case of any KDE user ever "handicapping his or her system" by slapdash changing of file types?
It may be that the bug database for Debian is structured in such a way as to distinguish "bugs" from "design change requests". However, the supercilious attitude this developer assumes towards a voluntary bug submission is way too common in computing. Open source projects trawling for contributors often proclaim 'if you can't code, file bugs!' but if this is the attitude a bug filed in goodwill can expect to generate, don't be suprised to see your userbase ossify out to 99% hard-core developers and only 1% or 2% OSS newbies.
It's an unfortunate fact that development often looks down upon test, not the least because QA is staffed by typically less-educated or -skilled individuals. Keep in mind, however, that without this buffer of moderately knowledgeable testers between consumers and devs with their fingers stuffed in the code, many key issues of usability and quality will be pooh-poohed right out the door. The dialogs aren't consistent? Well who gives a fuck! They work, don't they? Ship it!
When you're getting QA input for free, don't look a gift horse in the mouth.
-konstant
Yes! We are all individuals! I'm not!
-konstant
Yes! We are all individuals! I'm not!