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.
Alright, I have several issues with this article, chief of these is the way the author goes on and on about not having beef with Corel then going out of his way to demonize them. Now ever since MSFT crushed Corel's Wordperfect with Word the Corel people have wanted revenge on MSFT one way or the other. Corel's current CEO is constantly criticized by business magazines for his foolish obsession with getting back at MSFT and their current involvement with Linux is simply part of this obsession.
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.
"To be honest, EVERY SINGLE PERSON who works on KDE is subverting it, in a sense. They are working on "...
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.
I think we've pushed this "anyone can grow up to be president" thing too far.
Well, in some ways that is what Linux and the GPL are all about. We're going to develop software that is free of the tyranny of the corporate strongarm. We are going to develop an OS that has everything we want, how we want to, and when we want to. We are going to develop applications to go with it! We aren't going to let some company tell us what should and shouldn't be included for features, or how we should write the code...
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.
Not to mention recursive conflicts... :-)
It's not funny till someone gets hurt.
Heh. If, for some reason, one were into difficult, yet incredibly geeky T-shirts, I like this for a quote: ;^)
"... 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!
main(O){10<putchar(4^--O?77-(15&5128 >>4*O):10)&&main(2+O);}
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
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.
The commercial developers will make what they want, and, if it helps the free software developers, good. If it doesn't, at least their code is under the GPL, in case we want anything from it.
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.
|/usr/games/fortune
I am in the envious position of being a QA engineer in a company and culture that *respects* QA. But occasionally we get a new hire developer that smarts off to QA, so I understand that attitude you're describing. It's even worse with Open Source projects, since the developers have higher ego levels.
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.
A Government Is a Body of People, Usually Notably Ungoverned
Of course there will be problems. Corel is trying to make a product that is easy for the end user to understand. Like the line in the article about making their distribution look as much like Win95 as possible. There is nothing wrong with this. I do think that Corel should not be sending 100+ asthetics(sp?) issues to KDE.
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.
This guy seems to have missed it big time. His whole premise seems to be that production of shrink-wrap, for sale at CompUSA software (like Corel Products) is what most Companies do. I've been working in the corporate software development world for almost 10 years now, and I've NEVER produced a shrink wrap product. I don't know anyone who does. MOST software development exists to add content to services; commercial/industrial data collection, process control, stuff like that. The myth that corporate development of shrink-wrap software is what employs programmers is just that - a myth. The problem for the shrink-wrappers is that free software will soon replace it; if a few years, noone will be making shrink-wrap software. And if free software doesn't web-apps will. Its doomed. BTW, several people in my office use Corel, and they really like it -- seems if you use Windoze, its easy for you. Corel may be successful as a Linux distributor, but they WILL NOT BE AS A REPLACEMENT FOR M$. Noone will. The sooner they wake up and realize that the value they provide people is in an easy bridge from Windoze to Linux, and not as a provider of Office Apps, the sooner they will make money. Its the service and knowledge you have, NOT the fact that you have the magical program that noone else does.
--Rich
Free your mind and your Ass will follow -- George Clinton
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 development has taken place, for example, even though EST 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, and finding people who have the skills we need, in this industry, has been difficult.
-E
Send mail here if you want to reach me.
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.
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.
- 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.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.
They've also contributed significantly to the WINE project, yet the author COMPLETELY missed that aspect. Hmmmmmmmmmm.....
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?
Bite my yammer.
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
Send mail here if you want to reach me.
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
I had a
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.
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.
Information wants to be anthropomorphized.
So if I report bugs, or give suggestions, I'm just another person who is "unwilling to do the work"? Corel's ideas about UI bugs might not match up with the KDE team's, but they still should be considered. It's called 'feedback', and it is what any software project needs in order to grow.
-[Blaine]- "'Oh dear,' says God, 'I hadn't thought of that,' and promptly vanishes in a puff of logic."
I for one am very glad to have corporate involvement in open source projects such as KDE.
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.
meh.
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
The last scintilla of doubt just rode out of town
If I remember right, the IETF *requires* that there be two different implementations in order to ratify the RFC. (And incidently, they strongly frown upon anything based on patented technology.)
The GPL has similar requirements, so I wouldn't worry.
make for good neighbors.
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.
Aah, change is good. -- Rafiki
Yeah, but it ain't easy. -- Simba
He is saying, "This hasn't been a problem so far... but think about a scenario where Corel suddenly hired the core KDE dev team or provided them with 'valuable considerations'"
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.
This is pretty much what I was trying to point out.
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.
-[Blaine]- "'Oh dear,' says God, 'I hadn't thought of that,' and promptly vanishes in a puff of logic."
Does the Kde project itself have any kind of formal organization? Is anyone in charge?
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.
Ed Avis:
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.
Lacking <sarcasm> tags,
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.
What's the problem? Even if Corel (for example) did become boneheaded and started submitting duff code for inclusion in KDE, the core developers could just reject it.
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?
-- Ed Avis ed@membled.com
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."
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.
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."
--- Hot Shot City is particularly good.
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.
If anybody has a copy of Rhapsody for Intel to give away, drop me an email.
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.
There is no such thing as luck. Luck is nothing but an absence of bad luck.
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
Call this a flame if you want but BOO HOO HOO. You chose the GPL for your software and this is EXACTLY the behaviour that it allows. It allows for code forking, modification, etc. Don't cry too hard though - at least it's not a BSD style license so the code is still being released. Eric Raymond's "unwritten rules" that all open source developers understand, discourage code forks and other "rude" behaviour. Companies like Corel feel they can influence a development path and, unfortunately, they're right. You don't have to incorporate their changes but they can go wandering merrily off down their own path. I'm not sure who said this but it seems apropos: "When you dine with the devil, use a very long spoon." We WANTED commercial companies to develop for Linux. There's bound to be consequences.
In Soviet Russia, hot grits put YOU down THEIR pants.
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.
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!