When Volunteer And Commercial Developers Don't Mesh 132
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.
Scaremongering Article (Score:3)
Now Corel is paying designers and developers to work on turning KDE into a Windows-clone (i.e. a Windows beater), there's nothing wrong with that. What gets on my nerves about this article is the way the author trivializes the role of the KDE developers in this article. Corel does not pay any of the core developers salary nor does it contribute significant code that would die without their involvement. So basically the scenario is "Corel makes suggestions, KDE developers either like it or forward it to dev/null". If Corel really gets pissed off, they can fork the codebase (after all even Open Source developers have irreconcilable differences vis a vis Emacs and Xemacs) but if they realize they can't all they can do is keep making superficial changes and turning in bug reports.
Thus my question for the author is "So what's the big deal?". In any large project it is impossible for everyone to agree or have the same ideas and vision, simply because people have different goals doesn't suddenly mean some impending disaster will destroy the project. After all, IBM and the Apache developers have different goals but this hasn't stopped IBM from being one of the company's that gets it nor have their contributions been trivial. This article seems like a storm in a teacup to me.
Just my $0.02.
Re:Of course this will happen... (Score:1)
For example, I'd like a real active desktop. I'd like to have icons that change or move around based on relevant events. I want a screen background that has my Slashboxes and tips about what I'm doing in windows. I want a graphical shell interface (at least this one I'm doing something about...).
This guy is clueless (Score:1)
He asks Stallman about the issue and Stallman says he is the wrong person to ask. Then, instead of feeling like a complete goober and going off to ask someone else, he quotes Stallman saying he should not have been asked.
In addition, there's the initials thing. I think I've heard Stallman referred to as RMS nearly as often as I've heard Raymond referred to as ESR.
Attention moderators. (Score:1)
BTW the parent is not (Redundant). It is an insightful comment that restates some previous comments.
Re:How is this a problem? (Score:1)
Re:How is this a problem? (Score:3)
The problem is one of centralized control. Corporations (and Entrepreneurs generally) seem to have an inherent need to control the process, and to make decisions that should be made on engineering (programming) grounds on other grounds. E.g., how does this fit with our product line-up. This tends to strengthen the corporation at the cost of weakening the product.
Good and bad are, of course, relative, and subject to decisions. I tend to consider it bad for a small group of people to be able to control a larger group of people. (Well, I also consider it undesireable for a large group to control a small group). The problem is weigh various trade-offs, and of course that gets quite complicated quite quickly (degree of control x number of controlled), and who is exerting what amount*kind of control is something where one can expect different individuals to have very different opinions.
Re:Similar bit happened to me (Score:1)
If they are making decisions like that for the web site, what are they doing for the rest of the company?
I mainly use MS products for web sites, but even I wouldn't rock the boat like that. I think you can see it coming and it isn't going to go smoothly.
jas
Re:Scaremongering Article (Score:1)
Re:dumbing down is a Good Thing (Score:1)
Split is more subtle than you allow (Score:1)
It's better for user interfaces to evolve. They do evolve - nobody innovates. Innovation is a MS buzzword. In the real world those involved in coding and designing user interfaces stumble upon improvements in design - often in the process of coding rather than by using top-down design specs. This also seems to work better - evolution in a natural way. Such "discoveries" then are worked back into the design specs to allow yet another level of evolution.
Contrary to another myth, experts in UI design who do not code and do not understand the code are of little value to a project. All users have feature requests and respond to ui changes at various levels. So-called design experts can contribute little to this process of give and take that an ordinary user cannot contribute. Of course feedback from users is of great value, but the key is to get feedback from a wide range of users, not just the user interface "experts".
Very often such consultants and staff in commercial software development have rigid or preset notions of how things are "supposed" to be and try to dictate specs to coders without making an effort to understand what is required to implement such changes or how something similar might be better accomplished using what is already available in the existing code base. All too often these project planners get the ear of management because they specialize in office politicing while coders are too busy writing code to consider politicing important (and all too often change jobs before work on current projects are anywhere near complete). Paradoxically, because staff involved in spec writing and project design have less marketable technical skills, they tend to stay at companies longer and have more influence than coders who come and go.
So long as those who hire programmers tend to punish age and experience and reward those who move from job to job to boost their salaries without ever staying at one place long enough to learn any useful skills or finish what they start, the situation will not improve. To say that there is any relationship whatsoever between marketability and value is a bold faced lie in the software industry. It's 90% hype. Ouright lying about one's qualifications is expected. Nevertheless somebody has to do the work. Usually the real work is done by less marketable employess who stay with an employer longer and do not make a career of lying and hype because they really ENJOY coding and development work. In other words, knowledge, skill and noble personal qualities like loyalty are punished. It's almost a miracle that software is as good as it is these days.
Many free software projects are not so much affected by this because developers work on them mainly as a labor of love (even if they are also paid) and tend to stick with projects longer. Just the opposite of commercial work, loyalty is respected and quitting a project when the going gets tough and blaming others is not rewarded. But it is rewarded in the commercial software world, where they key to success is to take responsibility for nothing and to remain a moving target for those who are more adept at passing the buck, which is the only thing which is really rewarded in the commercial software industry.
For this reason, Kde is very, very different from MS Windows at very many levels including the user interface, if one gets beyond the most superficial aspects of it.
The only UI users need...... (Score:1)
~ $
everything else is just chrome......
Re:Conflicts are inevitable really (Score:1)
I tend to lean more to the GPL position, but feel that the BSD position is also feasible. But it requires much more altruism on the part of the contributors. I feel that this would slow development.
OTOH, just for security it would be a good thing if every important project had two separate development trees (like KDE and Gnome for the Window manager project).
in the face of the corporate strongarm... (Score:2)
But...
There is one minor problem here. What about "everyone else"? Besides the great hope of being saved by Mac OSX, what does Joe or Jane computer user/putz do to save themselves from these big old corporate meanies? Well...unfortunately they can't.
The nice thing about open source is that we are free of restriction. The bad thing about it is that without restriction and limitation, we have chaos. Is uniformity always good? No. Can it work to our benefit sometimes? Yes. When some company is working with volunteer developers and trying to set rules for the development, that is not always a bad thing. Someone has to set the goals and define the paths to accomplish them. As a group the linux development community could accomplish tons more if they were willing to accept some strictures in project development that allowed them to program a bit more in concert.
I do not mean to downplay the need for freedom to innovate here. Please, innovate your ass off, all you like! But we need to do it with some guidance. Maybe not the guidance of Corel, but we need it from somewhere.
Re:Conflicts are inevitable really (Score:2)
Not to mention recursive conflicts... :-)
Re:Good example of the difference between RMS and (Score:2)
"... I am not a supporter of the open source movement"/Richard M. Stallman
If your brain isn't completely turned on, and loaded with the difference between merely open source and truly free software, that one can really confuse things completely!
Reasonable Points (Score:1)
One of Corels objectives is obviously to ensure that KDE turns into a GUI that more people can use, and thus increasing the number of people who might buy Linux from Corel.
Developers of software products tend to be very insensitive to GUI related issues concerning their products, and the most trivial of problems at the User Interface can prevent normal, non-savvy users from using KDE. If KDE (and other Desktop Environments, for that matter) wish to seriously give Windows the kicking it deserves, then attention has to be paid to these issues.
The writer of the article suggested that Corel wanted to 'dumb-down' KDE in some areas. Even this should be possible provided power users have access to the full might of all KDE features if they wish.
Re:Of course this will happen... (Score:1)
issue is choice not look and feel. (Score:1)
Re:Dev hostility to test (Score:5)
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 [kde.org] and this one [kde.org].
The truth is not always well written in a nice article linked from Slashdot, it's sometimes hidden in CVS logs
some thoughts on the article (Score:1)
While "QA Linux" may have gone about their constructive critisism in an a a more constructive fasion, rather than posting gobs of bug reports, it is tempting for the KDE team to then ignore them, this would be a missed opertunity to glean knowledge from a respected source.
Another thought I had was that while not all the suggestions are good for your average KDE user, it is probably worth considering how to make these ideas more feasable to implement as part of the packaging of KDE, that is, configurability.
In the article Dennis asked:
If a developer is "misbehaving" then they can have their CVS rights revoked, can't they? It is in Corel's best interests to do things the KDE way. The alternative is to branch, and I don't think that would help anyone.To be honest, it sounds like a lot of a fuss about very little. At the end of the day, its open source, and if it goes in a direction that any given group doesn't like, they can split off, but its in everybodys interests to keep things amicable, so the chances are, they will.
Thad
Thad
On making things look like Windows... (Score:1)
Re:dumbing down is a Good Thing (Score:1)
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?
Exactly! The goal of KDE is to put a Windows-style desktop on Linux, just as the goal of Eazel/GNOME is to put a Mac-style desktop on Linux. Both will help Linux gain more desktop users, and their existence will not prevent the current Penguinheads from using either a text console or their current favorite IncrediblyBloatedXWindowsManager, so I wholeheartedly support both efforts (by buying the retail versions, since I'm not a coder).
IETF (Score:3)
The main trend I have noticed from this is that the number of RFC's produced has increased dramatically, and there are now competing RFCs and drafts sponsored by different commercial interests that are intended to handle basically the same problem. This is in part because some of the companies in question use the fact that there is an RFC for their implementation as a marketing tool.
The upside is of course there are a lot more resources devoted to working on problems. I would imagine that the situation with Open Source software will be better than that in the IETF because GPL is not (yet?) a sticker that can be put on something to make it more marketable.
Re:Nobody's forced to accept changes (Score:1)
Re:Server Business? (Score:1)
Why do you wish that they "fail big time", when you've already stated that you don't care. It's obvious that you *do* care, and care passionately about what Corel does. It seems to be a personal insult to you that some company doesn't include you in their target audience. BFD. Get used to it cuz the world don't revolve around your butt.
Re:Read the bloody GPL (Score:1)
Well, it's quite simple (Score:2)
If it doesn't help, though, we are (as always) free to work on our own. And we are free to make KOffice and to ask Corel for their filters, just as they are free to say no.
Re:Dev hostility to test (Score:2)
I've long since stopped submitting bugs to Open SOurce projects. They invariably get closed as "not a bug", "not our problem", or "submit it to that other project".
It's doubly hard since there are no specifications whatsoever for any of these projects. This is just insane. If there's no specs, then it's only a bug if it crashes the application (if it crashes the system, it was someone else's fault). Those bugs you quoted may or may not be real bugs. Without specs there's no way to know. He wrote "What here isn't working as designed?" and I'll answer "nothing because there is no design."
I hope that the KDE developers don't listen to this turkey, and trust the bug submitter that there might actually be a correctable defect.
Re:How is this a problem? (Score:1)
Yeah, uploading them would have been worse, but was the "chance to discuss" the changes any better? Did they do this out of the goodness of their hearts? Or are they trying to turn KDE into the product Corel wants, but unwilling to do work? I see this as another case of a company that thinks they can get the Free Software (KDE really isn't libre, but oh well) community to do their work for them so that they don't have to foot the bill for the product they sell.
Corel is a company that has contributed to the free software community more than others, and it's not as bad as a lot of other "mainstream" companies that have "contributed." But, please! You aren't the only people working on this project! Your idea of UI bugs is not everyone's!
Re:balance (Score:1)
Of course this will happen... (Score:3)
I also don't think that there is anything wrong with Corel trying to "dumb down" their distribution. There are plenty of distributions that are fairly hard to install and use unless you've had unix experience. Some people don't care how the video card and the x server communicate, they just want it to work.
Re:Scaremongering Article (Score:1)
By the time Corel bought WP from Novell, it was already crushed by MS. It wasn't Corel's until a little while ago. WP 6 was the version that lost major market share, and that was mostly Novell.
Correction (Score:1)
Re:Dev hostility to test (Score:1)
Yeah, but do the dialogs work to spec is the sort of thing you should be looking at as a tester. Unfourtunatly, even for the few OSS projects that do have some form of design roadmap and full specification details behind them, how many people know where to find them? How many people would bother to read them if they had them?
If the people submitting "bug" reports generally don't know and don't care about the diference between a "bug" report and a "feature request". In order to make the testers aware of the distinction, OSS projects need to start making specification documents available for people to check against before they submit either a bug or a request.
Oh btw, not the least because QA is staffed by typically less-educated or -skilled individuals.
You're knocking me (and yourself), surely? I wouldn't consider myself less skilled than any of the neer-do-well coders we have in my place; they can't even find their own bugs...;)
And the point is ? (Score:2)
--Rich
BRAVO! (Score:1)
Now someone levels a similar criticism at KDE and everyone says "That would be dumbing it down!" Fact is, if you were responsible for systems and an endless line of stupid users kept changing file types because they didn't know any better, you would be complaining because it was too easy to do so.
You can't have it both ways...either all OS GUI functions should be made as dummy-proof as possible, or they should be designed to be as efficient as possible for someone who knows what they're doing. Or maybe, there is actually a level of compromise somewhere in between which is exactly what the Corel GUI designer was trying to suggest???
That's not the point... (Score:3)
This happens within commercial companies too, BTW. What we do, when that happens, is move that person off that part of the project onto something else where he can't hurt the development process. I know that I find it irritating when some dude we hired off the street, who doesn't have any experience in our industry, starts telling the two seniormost programmers in the company "how it should be" without listening to a bit of our input as to what functionality the GUI needs. Unfortunately, the KDE team can't move this Corel guy to another part of the project, all they can basically do is "fire" him by putting him in their kill filters.
I don't know what the solution is, other than have people with experience in the free software community be the ones who the commercial companies hire to do the work. I don't think anybody has had any objections to the way further MTX [sourceforge.net] development has taken place, for example, even though EST [estinc.com] paid me to do the work of bringing MTX up to date to work with the latest/greatest tape libraries. On the other hand, people with experience in the Linux industry or with Open Source are rarely in the job market -- I know, we've been trying to find some of them to hire [estinc.com], and finding people who have the skills we need, in this industry, has been difficult.
-E
Re:Scaremongering Article (Score:1)
This is a point that will come up -- given the rate that this is all happening, probably sooner rather than later!
Re:Bound to happen (Score:2)
That comment should get moderated up.
There are some good people working at Corel, and Corel has had to support a large customer base. To them, KDE looks like a well-intentioned class project that needs someone to come in and crack the whip. Most garage bands could use a producer when they record, though they'll insist their own artistic judgement is good enough. But it usually isn't, which is why producers exist in the first place.
Corel is making comments that push KDE toward being tighter and more polished. The KDE developers would rather play at being midnight developers, in the same way that junior high kids like to play at starting their own virtual game companies (by designing logos and websites and making announcements about engine features). KDE is on the right track, but it's still crusty. It needs some help from people who aren't blind zealots.
UI design - it's not about menus (Score:2)
- Open up Microsoft Word. Type a few words. Select and copy two words. Note that the selection includes the space after the words. Now select another word, including the space after the word. Paste. It works; there's only one space after the word, but that's what you'd expect.
This is subtle, but right. Notice that it's not a "feature" in the usual sense. It's just "the way it works". You've probably never noticed this, even if you use Microsoft Word regularly. That's what UI design is. Go read The Inmates are Running the Asylum. [amazon.com]Now select another word, without selecting the space after the word. Paste. It works right; there's still only one space between words.
Now put the cursor between two words and press the space bar. You now have two spaces between words, but you only get that if you explicitly ask for it.
It's hard for feature-driven software development, be it commercial or open-source, to get interactions like this right. It requires mockups and detailed observation of users.
Re:Bound to happen (Score:3)
Personally (and hold the flames, this is my opinion a concept many slashdotters have a hard time dealing with) I feel that WINE is a giant waste of resources. I don't think we should try to promote the user of the Win32 interface on top of Linux. Win32 is well known to have problems even running on it's native OS, why do we think we will make it better by putting Linux under it. WINE runs things just like they run on Windows. There is this persistant crashing problem that programs under WINE exibit (just like under Windows). Why do we want to turn Linux into a clone of Windows? I thought the whole purpose of Linux was to be an inexpensive alternative to proprietary Unix. If you don't think I know what I am talking about, feel free to email me (my real address is right there) and tell me what an idiot I am. I've heard it before and it still hasn't changed my opinion. Win32 should stay in Windows land. It was something I tried to leave behind, yet even under Linux applications are dragging it along.
I loved Corel when they had a real Unix/Linux version of WordPerfect, why did they have to use the Win32 version for WordPerfect 2000? Just another attempt to use Windows software under Linux, and it will make Linux look once again like a cheap (and bloated) Windows clone. Why?
complying with spec vs no bugs (Score:1)
In reality, you can't use complience with the spec to determine if something is or is not a bug. Someone needs to look at the issues, determine if they are worth fixing, and assign some sort of priority if they are worth fixing.
Re:Similar bit happened to me (Score:1)
They hired a person that was an egineer to be the "network administrator". Since he was the only one there that knew how to hit the power button, he was elected when it was decided they wanted Windows instead of basing everything off of the AS/400. Not that that part was a bad decision per se (but I would have chosen another solution) but they picked someone that had a computer at home (he must be good because he knew how to change the toolbars in Word) to be the computer expert for the company. Oh well, in twenty years that company won't exist anymore, and niether will the company that I am at now (they are doing everything they can to be a clone of the previous company) because they make stupid decisions. Unfortunately, that is the way things are now. No one thinks in terms of long range goals. They look at something and say, "We need something quick, we need it cheap, and we want it NOW!" and forget all about trying to make something that will last. But that's what America is devolving into, a cesspool of stupidity.
Yeah for us....
Team development (Score:2)
Commercial programmers coming into the Open Source world have two basic problems: 1) lack of face-to-face communications. EMAIL is quite limited compared to face-to-face and it is easy to give the wrong impression -- or get the wrong impression -- when all you have is flat text to go by. And 2) Lack of knowledge of the basic "culture". Part of which is "what have you done?" rather than "what is your position?", something especially confusing to commercial software project leaders and managers who are accustomed to coming in an "managing" a project. If you try to "manage" an open source project, the programmers will simply add you to their killfile and you can rant and rave as you like with no effect -- something extremely disconcerting to these types.
'Nuff. Time to get back to work (took this break 'cause I was getting frustrated with the program I'm working on, which will write, read, but won't do both during the same invocation...AGH!).
-E
Re:This is what Linux needs. (Score:1)
And before I am corrected, I already know that scene in Braveheart is not based on reality. Most of the movie wasn't. I've read several books on the subject of the real William Wallace, and the movie was more based on the legend of Robin Hood mixed with some of the actual story of William Wallace mixed with a little more of the word of mouth legends of William Wallace that developed over time. The movie itself alluded to this as they showed scenes with people talking about things after the fact and making the stories "larger than life".
OK, sorry about the off topic bit.
Valid concerns but lets not lose hope. (Score:2)
An insightful article, raising many valid concerns for the future of both "free" and "open-source" software. I am personally convinced that the ESR quote was correct, that the current paradigm of software development is not going to be sustainable for long. Companies that develop software in all but niche markets will sooner or later have to open their source or they will get overwhelmed by others that make use of the benefits of open-source development. Corporations are of course ultimately in it for the money - they have no other reason for existence - and therefore every penny they spend is in some way intended as an investment that should show some kind of return, financial or otherwise. Every product they produce is intended to be a revenue stream. The problems described by the author are all derived from this fundamental problem, that if the ground rules of software development are to change in this way then companies are going to have to find some other way to generate revenue streams from their products.
Lets look at this for a moment.. Do you see anything wrong with a company turning a profit from their work? I sure dont, if the guys I worked for didnt profit from that work I'd be broke too. This means that open-source/free software has to show a profit of some kind for a company to want to buy into into it - So how can they make that work? The main "profit" from companies working with open source software is the help they get from folks like us - the guys that not only submit bug reports saying "its broken" but go on to say "heres how I patched it..." Thats really great for the development of better software but a nightmare for a company that wants their product to be the one folks use and preferably pay for. They dont want to GPL anything they can safely keep to themselves and sell... So how about they sell the current version, without source but with all their support services etc.. but MajorVersionNumber-- is available as source for you to compile, use (and support) yourself if you're happy doing that and dont need all the bells and whistles of the current version. There'd be enough new code in the new one that the company keeps its competetive advantage (or at least there damn well SHOULD be) but enough similarity between current and previous that the tweaks by the open-source community can be useful to the in-house development team even if the patches cant be directly applied to the in-house code. When a new version comes out on the commercial side, the source for the previously current version is released and the cycle starts again.
Before you all start flaming that this perverts the nature of open source, Yes, sure it does, but will it work? It carries many of the benefits of true open source for those of us that dont need all the bells and whistles of the latest version (How many windows users do you know who actually use features of office2k that werent in office97?) and it gives the companies what they need to survive as well. Plus its an arrangement the company cant renege on, since if they do theres the previous versions source out there ready to spawn a new open development tree if they try to back out and close up the source again. I bet neither RMS nor ESR would like it though :)
# human firmware exploit
# Word will insert into your optic buffer
# without bounds checking
Re:That's not the point... (Score:3)
But it's not the KDE Team that has got these problems, it's Dennis E. Powell aka "dep"!
He was ranting on the mailing list until enough told him that they didn't share his opinion and he should please stop spamming the list...
Bugs or Wishes? (Score:1)
Re:Nobody's forced to accept changes (Score:1)
Re:Bugs or Wishes? (Score:1)
A user interface deficiency is a bug, plain and simple.
Now there's no chance a software will ever be completely bug-free, so shipping with a known deficiency may be ok, but that doesn't make it only a "wish".
hmmm.... (Score:1)
Sounds like one too many layers of abouts to me.
No way he could have submitted the story instead of the commercial about the story?
Ever get the impression that your life would make a good sitcom?
Ever follow this to its logical conclusion: that your life is a sitcom?
dumbing down is a Good Thing (Score:4)
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?
Re:Whats the problems with bug submission by Corel (Score:1)
I think you are confusing a problem with a solution to a problem. If a user sees a problem, it is perfectly valid for the user to describe the problem. Depending on the user's viewpoint, the severity assigned to the problem may vary.
What you are talking about is a solution to a problem. That is upto a designer / implementer. If they choose a poor implementation - that is their problem. Sometimes, (as in the case you described), any solution is a bad one. So what? Nobody loses if a user describes their problem anyway?
Kerebros is NOT open source!! (Score:1)
Neither for that matter is Qt.
Kerebos was developed by one of those cumbersome collaberations supported by UNIX vendors which were so popular in the late '80s.
Kerebros is almost unique among these groups in coming up with a succesful and usable product. Other examples are the ubiqutious but plodding Motif toolkit and KDEs commercial ancestor CDE. Most of these comercial collaborations however produced real turkeys like DCE.
This may seem off-topic -- BUT -- the whole reason that M$ has been able to hi-jack kerebros software is that they don't have a GPL type licence. I always though the GPL seemed like paranoid overkill, but, it turns out that RMS was right and everybody is trying to kill us ;-).
Re:Bound to happen (Score:2)
That is a very valid opinion, from an engineering and design perspective, but in Real Life there are a lot of apps out there that are Windows-only, and more coming out every day. Many of them have small enough user bases that they are not worth porting individually, so being able to run an emmulator "for that one app" is a valuable asset.
Linux and Mac cheerleaders need to keep this in mind. There are a lot of users out there that find themselves saying, "I would use $SYSTEM all the time, except I need to be able to run $APPLICATION."
If and when Linux starts showing up on a large percentage of desktop machines, all developers will feel the need to produce Linux versions of their programs. Until then, WINE and TWINE are critical to winning users over, and ushering in a time when they are no longer needed.
Re:How the GPL protects a user community (Score:1)
I wouldn't be too sure. Talk to some of your brothers in the righteous fight against copyright and MP3. If they win, and copyright laws are greatly weakened, that breaks the teeth right out of enforcement of the GPL.
Re:Fences... (Score:1)
That doesn't mean that the styleguide can't be changed (after due review) if it is inconsistent or broken in some aspect (and some sections aren't finished yet).
Re:Fences... (Score:1)
Re:How is this a problem? (Score:2)
Re:Read the bloody GPL (Score:1)
And sacrifice our principles? (Score:1)
insist that *EVERYTHING* be open source.
Selling support contracts or other services
is ok, but creating 'commercial playgrounds'
for software is just bad.
Re:Regarding socialism and anarchism (Score:1)
Socialist are most definately not libertarians, and anarchists are certainly not democrats. Also, corporate welfare does not really adhere to capitalism; free-market capitalist purists despise all corporate subsidies. You are confusing "capitalism" with "those damn Republicans".
Let us begin with socialism. In a nutshell, it means that the state owns all property. No private ownership is recognized. Or, as Webster put it... 1 : any of various economic and political theories advocating collective or governmental ownership and administration of the means of production and distribution of goods 2 a : a system of society or group living in which there is no private property b : a system or condition of society in which the means of production are owned and controlled by the state 3 : a stage of society in Marxist theory transitional between capitalism and communism and distinguished by unequal distribution of goods and pay according to work done
Now for anarchy, which means the absense of recognized rulers. Each person is responsible for protecting their own rights, including property rights, because there is no govorning authority. Again, turning to Webster... 1 a : absence of government b : a state of lawlessness or political disorder due to the absence of governmental authority c : a utopian society of individuals who enjoy complete freedom without government 2 a : absence or denial of any authority or established order b : absence of order : DISORDER
In short, the post you were responding to is correct. You can't have state ownership of property if you do not have a state which governs that ownership, and you can't have total freedom from governing authority if you allow all property to be controlled by a governing state... therefore socialism and anarchy are entirely mutually exclusive. QED.
How some people choose to define themselves is irrelevent. If you do not believe that the state should own all property and control the economy, you are not a socialist, just a Democratic Party member with a Karl Marx T-shirt. If you consider government to be a "necessary evil in some situations" you are not an anarchist, just a kid who likes calling himself that because it sounds cool.
Re:Dont' Worry, there is a solution! (Score:1)
You mean this hasn't happened already? :-)
A GPL question (Score:1)
Re:How is this a problem? (Score:1)
What is different here is that the developer has been brought to the project from a non-open source background. Open source developers have previously come to write stuff because they have an itch to scratch - they want to help develop the software so much that they are happy to do it for nothing, in their spare time.
There is bound to be some conflict when you bring people to a project who are there because they are paid to be rather than because they really want to be there, although sometimes the two will happily coincide.
Open source projects are usually run as a meritocracy, so if the people that Corel is paying to work on this are not doing anything useful, their code won't make it into the main CVS tree. This is one of the great things about open source development - qualifications and experience count for little compared to the ability to produce quality code.
Journaling File Systems (Score:1)
Reiser want the advantage of being the first journaling file system in Linux. If they don't make it for 2.4, IBM's JFS and ext3fs (?) will catch up and be competition.
__
The other way around (Score:1)
To use this case as an example, to the extent that Corel really is getting 'something for nothing' from the KDE developers, it is in their best intrest to try to steer the project while rocking the boat as little as possible. Basically, the guy coming in and making a bunch of demands before he proves his worth is a total bonehead.
I'd like to hear more from some of the volunteer developers what type of support they _do_ want, and how corporations could interact with them more effectively.
It's not the actions, it's the trail (Score:2)
Corel's modifications to KDE (if given back to KDE) are perfectly legit, but these same actions have the potential to bite KDE hard.
I have always envisioned Open Source as a sort of "free market" darwinism where changes are jockeyed about and dominate features eventually replacing weaker features. Some where along the way then, the project inevitably forks and multiple versions emerge as "viable" in the environment either for a long term or for a short term. I'd like to believe that normally forks are short term events and the project merges back together. These are the kind of forks that serve the project best (by not splitting the codebase in the long term).
But now with deeper pockets backing one vision, a fork can be carried beyond what it should have because money can keep bad code alive. It will become easy to let weaker visions live longer. I'm not saying it's happened, but the potential is there.
On a different note, I'm not a fan of Corel putting Copyright notices in KDE distributions. The integration of proprietary and nonprorietary pieces inside a product like this is a clear rode to Hell. We go from being a "licensed open" free people to "lawless pirates" overnight because the typical user doesn't review every license in his or her distribution before they install it on dozens of machines.
And in closing, I'm ok with Corel wanting to simplify the look and feel for users assuming:
1. We don't lose advanced user functionality that is easily accessible.
2. We don't assume that a mirror image of win9x is the best a UI can be.
Re:Why it is scaremongering. (Score:1)
I'm not sure that is entirely accurate. Linux UIs have been designed in the past, therefore they must have had a designer (we're assuming that KDE code isn't evolving on its own yet). Maybe not a professional designer, but a designer nonetheless. I understand the assistance that a professional UI designer can bring to a project, but you can't just say that no Linux UI design has occurred in the past just because it wasn't done by a professional.
That aside, I think the article did unnecessarily vilify Corel. If you're going to set up an open source project, you have to be willing to accept comments from anyone. You don't have to act on those comments, but it would be a mistake for the KDE team to tell anyone, whether Corel or a total Linux/KDE newbie, that their comments aren't wanted.
One point that the article didn't touch on very much was that you have a greater chance of your comments being acted on if you provide patches that implement them. Then it's easy for the user base to try them out and come out in favor of the changes. Just tossing out suggestions, especially in a field like UI design that a lot of coders admittedly don't have as much experience with, may not arouse a lot of interest. Submitting a patch and saying "hey, look how much more understandable this dialog is now" is almost always better.
Re:A GPL question (Score:1)
The GPL only covers software you distribute... The whole premise is that if I have acquired software (from someone else) with the rights covered by the GPL, and I give (sell or otherwise distribute to) you something derived from it, I must give you the same rights I had to the original. The GPL, however, seems to ONLY cover distribution, I can do whatever I want with GPL'ed code so long as I keep it to myself. This is a simplistic explanation, but one which appears to apply in almost all cases.
-- Rich
-- Rich
Re:How is this a problem? (Score:2)
Corel have years of experience of real end users who have spent real money on their products, and the priorities and perceptions will be different to those of hackers. Rather than a source of conflict, this should add another viewpoint to the peer review process, though posting 142 bugs in 2 days is not a good way to introduce yourself. This will make the KDE cake bigger in the long run.
On the subject of filters for KOffice, Corel would make a lot of friends just by publishing a specification of the internal formats of the various products which import into Corel office. This would start us down the road towards making commodity file formats rather than proprietary and closed ones. The competition for Corel office isn't KOffice, and won't be for a year or two yet, it's MS Office. They can't win by playing closed and proprietary file formats, the way for them to win is by making WordPerfect the best engine for manipulating documents. If we had open formats from Corel, Sun (Staroffice) and IBM (Smartsuite) to go alongside those of KOffice, Abiword, Gnumeric etc. then we can begin to talk about commodity office software rather than extend and embrace.
Oh, and Sun should make StarOffice libre as well as gratis.
Dunstan
This is what Linux needs. (Score:1)
This won't happen unless industry gets into it. Period.
Re:How is this a problem? (Score:1)
No, you do not (I hope not, at least). You're an adult (or close enough, at least). You can just change the code. If Corel wants to change KDE's interface to conform to their expectations, they should do it themselves instead of trying to force the world to change along with them.
This isn't feedback. This is Corel trying to get KDE to change their opinions to match Corel's by reporting where the KDE team's opinions differ from Corel's as problems that need to be fixed. This is Corel trying to get the KDE team to do what they want instead of just changing the version of KDE they distribute to do what they want. There's already a Corel Explorer. Why not just make the rest of a Corel KDE instead of telling the KDE team they need to do it? If the KDE team likes it, they can change the main version. If Corel wants to tell the team what it thinks KDE should be like, they should suggest not consider it a problem that the KDE team needs to solve.
And the problem is what? (Score:1)
who has problems with Corel submitting bugreports.
The UI of KDE and the usability of KDE are very
important for KDE. We have a KDE user Interface
style guide which describes how we would like to
see KDE applications behave. If an application,
_FOR NO GOOD REASON_ does not behave like
that then that's a UI-bug which we would like
to correct.
Corel does quite a good job in finding such bugs
and I think that that is good thing for everyone
(developers and users) involved with KDE. Corel is
not the only one btw. which reports such bugs, we
have a lot of dedicated beta-testers who also make
us aware of UI inconsistencies.
I can understand that, after twenty years of Microsoft
software, people seem to consider software that
doesn't crash bugfree, but KDE tends to put its
standards higher than that.
Cheers,
Waldo Bastian
bastian@kde.org
(Employed by SuSE)
--
Make way, KDE/Linux is coming to a desktop near you!
But... (Score:2)
The GPL has similar requirements, so I wouldn't worry.
Fences... (Score:2)
When people know where the boundaries are there is less chance of conflict over where they should be. The impression I got from the author is that he has trouble with Corel pushing the UI in a particular direction. But there would be no need to push in any direction if the software development counterpart to fences, design guidelines, were in place.
A bug report says that a dialog should say 'Close' vs. 'Dismiss'. Why isn't there a design guideline for this? If there was one, the report could be answered succinctly; either, 'you're right we'll make it conform to the guideline', or 'RTFG' (read the **** guidelines). The more detailed the guidelines the fewer the 'issues' over silly issues.
I haven't been involved with the development of KDE, so I don't know what they have set up. But it sure does sound like they need to stop coding and develope a complete set of UI guidelines. That move will make the UI ready for end users faster than anything else they could do.
Why it is scaremongering. (Score:2)
Two reasons why this is not an issue.
a.) The KDE developers are talented programmers that are working on an open source project because they want to. Programmers like them can easily find jobs if the job they are currently in violates their conscience. So even if they were hired by Corel and asked to compromise their vision, they would not.
b.) Secondly even if the entire KDE team somehow decided to sell their vision for corporate $$$, the code is GPLed and can be forked by any number of willing and able developers. A project as large as KDE cannot and will not die because it affects way too many people.
PS: That said, there are many instances of scare mongering and Corel bashing in the article.
But here a company that, for perfectly good business reasons, wants its Linux distribution to behave as much as possible like Windows has hired a UI designer with no Linux or open-source experience to be a "UI designer for KDE."
At GeorgiaTech (where I go to school), there exists one of the premier Human Computer Interaction programs in the country and I interact with several people in this program. Now from my understanding, it is simply not possible to be both a UI designer and have Linux experience simply because until the past year there was no Linux UI design experience to be obtained by a professional designer. After all, most of the UI designs for Linux were/are done by coders and hackers , not a UI design team. So it is rather unreasonable to expect to find an experienced UI professional with Linux experience. If anything the first generation of them are just about to start.
Even greater in number are the items reported as bugs but that are internally listed as "wishlist" items
This attempts to trivialize the Corel teams bug reporting when in truth it should be thankful for them. Linux users are always hollering about world domination but once someone offers suggestions that contradicts the developer mindsight they are jumped on. Now here are two truths from MSFT: Of the 65,000 bugs or issues reported for Windows 2000 at least 20,000 are considered UI or wishlist issues. For professional shops...wishlist or UI issues are almost on par with bugs depending on the amount of functionality they add. Secondly it would surprise most people but from a reliable source MSFT studies showed that almost 90 per cent of developers hate the dancing paper clip while a majority of users like it, guess who won?
Without companies like Corel providing the much needed real (l)user feedback that OSS projects need then this talk of world domination will be just that, talk. They should be thanked for their input not vilified.
Is there concern about a project being taken in a direction that might benefit one company over others?
Red Hat has lots of developers working on the kernel yet no one asks whether the kernel will be optimized for Red Hat but yet Corel that merely makes suggestions and bug reports is in danger of hijacking KDE?
Even uglier, one could imagine--and this example is entirely hypothetical--a situation where the top people in a development effort accepted what lawyers call "valuable considerations" in exchange for looking the other way as a project got steered in a way that benefits a particular company. Nothing illegal about it.
This one was just to offensive not to miss. I work as an intern for an e-bussiness firm and already am being remunerated more than most of my peers will be 5 years after they graduate. If I worked on an OS project, no one could offer myself (let alone several people as talented or more talented than me) enough money to sell my vision. To assume such is to miss the very spirit of Open Source. Open Source developers code because they want to and not for any financial remuneration, that's what the 9 to 5 is for.
Re:How is this a problem? (Score:2)
Just because Corel is a corporation doesn't mean it can't scratch it's itch. Pretty much every OSS project in existence has started because somebody wanted a program that did 'X'. And pretty much every person who develops for said projects does so because he/she wants 'X' to do 'Y'. However, usually people don't see that it is 'subverting' 'X' , because usually everybody is in agreement over features and such.
However, sometimes different people want different things. Corel wants certain things, and so they've hired a guy to help enumerate this. Sure, he doesn't have OSS experience. But like I said, if the KDE team doesn't like the ideas, it doesn't have to listen. If nothing else, having a second (informed) opinion on something can only help. At best, it will bring you new insight, and at worst you will just have to say 'no' to it.
Kde needs an organization (Score:2)
It appears not to have one. But I could be wrong. Any comments from Kde developers? It appears that developers just submit code changes through a kind of democratic process in an informal way. This seems to work exactly the way open source should - those who do the most work and submit useful code and ideas get listened to and get their work included, and gradually assume leadership in an informally organized team. I do not think it matters much to the team whether or not a particular developer has corporate sponsorship.
This may work for Kde developers but gives the appearance to those outside that group that Kde is an easy target for corporate and other "steering" or for outright assault because it lacks a spokesperson and an organization.
No doubt there is a significant conflict of interest with Corel Office and KOffice. I mean, Corel Office is their main product. KOffice is in direct competetion with it. It would seem that Corel has a need to sabatoge KOffice.
I would also take with a grain of salt their UI expertise and numerous "bug reports" on UI issues. While Kde has, loosely speaking, many design features in common with Windows, it is very different from Windows in other ways and the main goal of the development team is NOT to make Kde as much like MS Windows as possible. Again, Corel has different ideas about that. Kde is a unix project - Corel is a Windows-centric company trying to also compete with MS on a platform where MS has no presence (so far).
All of Corel's products for "alternative" operating systems have just been, to date, bad ports of MS Dos and MS Windows products. Further, Corel and Word Perfect have not done a good job in the past of maintaining these ports, letting them wither on the vine much to the consternation of Amiga and Os2 users of Word Perfect. They just abandoned these ports to "return to their roots" in the Wintel world and contributed as much as any other single factor to the decline of Amiga and Os2. It's no different with Linux.
Kde may learn too late that the best development talent in the world and the best of intentions to meet the needs of users cannot make up for a lack or organization. There is a need for Kde not only to deal with corporate "steering" in a firm and decisive fashion, but also to better present its product to the world.
For example, the kde.org web site does not in any way reflect what a great product they have. In particular the "applications" section is a disorganized jumble and does not adequately describe the many fine kde apps available or where to download them or where their home pages may be.
Compare this mess to the apps section of the Gnome site which is well organized and further gets regular artistic facelifts from time to time to keep visitors interested at many different levels of experience.
Development news is also lacking. It does not in any way accurately reflect the current status of kde development and often has dead links. When releases are late, no explanation is offered. Persons who visit the site and who are not already very impressed with Kde do not find much at the site to give them a positive impression. In what ways is the current Kde 2 effort different from the existing, stable Kde 1.x product? These things are not explained to non-technical persons in a clear and understandable way that would help to better define what Kde is to new or potential users.
In spite of all that Kde has done well and is the most popular desktop for Linux and unix among users because of word of mouth and acceptance as the default in many distributions of Linux and BSD. But that may not be enough. Active, organized efforts by Kde to define its goals to the outside world and to meet challenges and threats are also needed, just as they are needed with any project with such a large scope.
Re:Nobody's forced to accept changes (Score:3)
BTW anyone know how many copies of Corel Linux, WordPerfect and so on are being sold?
Point datum: The local Frys stores say that they can't keep Corel Office for Linux on the shelves, and the channel seems to be dry.
Re:Valid concerns but lets not lose hope. (Score:2)
ID have been releasing the Doom & Quake series in source (the code not the artwork and levels) a while down the road and no-one has been ranting about how they should release the code from day one as source (would be nice though).
If a company chooses to provide any source code under a license which lets you use it, this is a good thing. If a company only works on GPL code this is a better thing. If a company keeps its knowledge and its code to itself I agree with ESR, they will die. The only companies I can think of that can survive free software's second coming are the BIG players such as IBM, SGI, Sun and these are the guys who have already seen that the light at the end of the tunnel is collaboration. We must encourage EVERY company that contributes to continue and maybe attempt to coerce them to do more or act differently, we must not berate them for how they think suits them to do it. As far as the greedy control freaks (you know who you are), fsck them, they will waste lots of money re-writing free software components and hence sell their wares for extravegant prices and as long as they are generating a worthwile revenue under these rules, they are another target for free software to replace (perhaps with the help of a friendly company).
Re:Conflicts are inevitable really (Score:4)
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!
Bound to happen (Score:4)
Is there a problem? (Score:5)
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.
Nobody's forced to accept changes (Score:2)
The article does make Corel sound a bit silly, but that must be because it's being selective. The KDE developers are free to ignore any 'bug reports' from Corel; OTOH, even if only one in ten is sensible, that's still a lot of useful bug reporting.
BTW anyone know how many copies of Corel Linux, WordPerfect and so on are being sold?
Re:Bound to happen (Score:2)
World Domination might not be the ideal goal for Linux. A free UNIX for geeks may be all that Linux ever really needs to be.
Conflicts are inevitable really (Score:4)
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.
How is this a problem? (Score:5)
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.
Re:Bugs or Wishes? (Score:2)
Judging from the article, it seemed that the bug reports were about conscious choices in interface design. If a UI doesn't adhere to the look and feel of Win 95/98 does that make it deficient?
Was it conscious or just something done? I'm a trained useabiltiy professional (THat is not what I do though, After going through the training I realised I hate that line of work) As a devolper I know the insides so well that anything outside no matter how ugly will work for me. I know in my heart that the users will have problems with it, but I cannot say where because the act of creating the interface destroies my ability to be ojective about it.
Buy a copy of Donald Norman's Design of Everyday things. It will change the way you look at the world.
This artical would have been okay if they made the point that the UI guy at Coral was focusing too heavly on the novice. That is an expert user would know file permissions and needs easy access to them, and therefore the right click menu is a good fast spot for them. (What novice will right click anyway, with Windows not using the rick click much?) However the point is correct, the novice should not be able to accidently break file permissions.
Good example of the difference between RMS and ESR (Score:3)
Stallman says: "I think that corporate contribution to any particular free software development activity is always welcome, but corporate influence in impeding the extension of free software to do an additional job is obstructionism."
Raymond says: "I'm not worried. What I see is corporations realizing that if they want our results, they have to buy into our process--and if they don't, they'll be eaten by a competitor who does."
/.effect already? (Score:3)
The objective of the distrobutions is not necessarily to produce comercial software (as part of the distrobution), but to give and identifying characterstic to the distro. For example, Corel's identifying characteristic is their file manager. (BTW, did the source ever show up for that?) Mandrake features DrakConf. Redhat pioneered kudzu in a distrobution (but it was also adopted by others). Everybody wants to have their distrobution be identifiably different from the others, and Corel's method is through customizing the file manager.
Corel's objective is not necessarily to produce a closed-source distrobution. They want to help the KDE project out, but in some respects they need to provide a different set of features to their customers than KDE does. Also don't forget that Corel's custom modifications to kfm are specific to how they have set up their distrobution in regard to samba support, where the filesystems get mounted, etc. They have a greater freedom to customize because they know how they have the system set up. KDE is distro-agnostic. Corel's desktop is a distro-specific hack of KDE. Is it their objective to fragment KDE or to destroy KDE? No, because they'd be biting the hand that feeds them. Remember that.
Whats the problems with bug submission by Corel? (Score:3)
What particularly ticked me off in the article was the statement that because their UI designer was submitting all these bugs, one of the possible consequences for KDE would be a dumbing down. The users, it was claimed were good enough at determining what a good GUI was.
My question is : what user group is being talked about? Are we talking about the same user group that understands the X-protocol, and knows what to do with netstat, and thinks 'vi' is the best editor (it is, but there is no denying that it is hard to reach an intuitive level with 'vi'? These are not the same users that Corel is trying to win over. As long as the acknowledged goal of any software product is to increase its user base, I dont see any problems with a commercial company with the same goals filing such defects.
Re:Conflicts are inevitable really (Score:2)
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.
I don't see this as a solution for the developers - it's more like capitulation to the very corporatism that you claim most open source developers reject.
Making a corporation of some sort out of the developers means tying all of them to the corporate policy. This would, if anything, make it easier for the money-making corporations to get their way because if they can change the policy then all the developers have to go along.
I think a better idea is to trust in the current "democratic" approach - and maybe support developers who have the courage to reject unwelcome changes coming from for-profit corporations.
Re:How is this a problem? (Score:2)
He may be aces when it comes to GUI development, but he may be a lousy diplomat. That may not even be a fair assessment since the article didn't say that the suggestions were coming from the new GUI guy at Corel, just that they were coming from a Corel address. Still, when you're the new guy on the team (or hoping to be) it's far better to sit and listen for a while and start by asking questions before offering your unsolicited wisdom, no matter how sage it might be.
carlos
Re:That's not the point... (Score:2)
From what I read, he does have considerable experience in writing user interfaces. It sounds like he went through the user interface in a through fasion and submitted the things he had issues with as bugs.
Things he did right:
1. Tested the portion of the software in which he has considerable experience.
2. Submitted all the issues at once so developers don't have to keep going back and revisiting the issues (hopefully).
Things he did wrong:
1. Submitted things as bugs that others didn't consider to be bugs.
Unless there's some history here that I'm not aware of, or he keeps submitting things this way after he's told to submit them in another way, this doesn't seem like a very big deal.
If you just move people off the project because you don't like their opinions, you end up with poorly designed products, which also happens often enough on commercial products. There's a balancing act to be done, and everyone on the project needs to be somewhat flexible.
Similar bit happened to me (Score:3)
The early anecodote ("We've brought in a new person, no experience in what you do but he's a really hot developer, really, please bring him up to speed") has happened to me this past week, ironically enough.
I used to co-run a niche portal site, under linux, with heavy use of open source tools (phorum, some nice php stuff, some stuff I developed). The new owners brought in 'some hot programming talent' that turned out to be underpaid interns.
They also brought in a 'content manager' who was going to take over the site... but didn't know html and keeps reformatting the stuff using some windows program.
In short, we went from a friendly linux-backed site that required maybe an hour a day of simple script running to update... to a windows-2k driven monstrosity that requires a team of programmers and still can't update each week.
The lesson I learned? Folks with money aren't web-saavy, programmer-saavy, or programming-saavy. What they think of as 'hot talent' means someone who was good at schmoozing while others did the work. And since they fall for sales hype, they choose expensive, unworkable schemes instead of the simple, direct method.
If you sell something or let the VC come in, RUN! Disassociate yourself! If you stay, you'll just have regrets.
I must remain,
Anonymous
Read the bloody GPL (Score:2)
balance (Score:2)
The key is not to allow any one voice to overpower the rest so that it becomes effectively a free source of development for the voice in question. Clearly companies who are releasing the fruits of the project commercially are the ones to be most wary of because they have to serve both the software and their paying users.
It seems that as open source moves into the spotlight more and more, there will be an increasing number of bodies joining the party and then trying to make it their party rather than everyones.
I don't however see any point in panicing. Providing the members of a community realise this may happen and remain vigilant they can easily try to minimise any negative aspects of the contributions of the corporations many seem to fear.
Dev hostility to test (Score:5)
"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!
Re:How is this a problem? (Score:4)
PLEASE, don't mix up people writing articles about KDE and KDE developers.
Most KDE developers are *grateful* about the comments, suggestions and bug reports sent by the Linux QA team.
This guy ('dep') can't stand Corel, that's his problem. Too bad really, because I like all the articles he wrote on KDE - except this one.
David Faure.