KDEvelopers on KDE Users

An anonymous reader writes: "KDE developers spent some time this week on their mailing list discussing what motivates them and the extent to which user concerns figure in their decisions. Dennis E. Powell's column on Linux and Main draws excerpts from the exchange, in which he participated, and says that he believes a lot more of this kind of discussion is needed."

Comments

problem no 1.: lack of tutorials and beginner docu

[Jondor]

I tried a few times to get up and running with KDevelop. Have a KDE programmers book at home, tried every tutorial I could find.. And the results? The KDE programming book doesn't use KDevelop and the best result up till now is a KIO slave for hello world..

What I found to be the biggest problem with KDevelop is the lack of up to date documentation and tutorials. Whatever I found was always based on older versions, different templates etc. I haven't found 1 tutorial which I could go through from beginning to the end and end up with the results I should accourding to the description.

KDevelop is attractive to programmers who are not fluent in KDE, C++ and QT and lacking basic, but up to date and included, tutorials is IMHO one of the biggest things that stops new programmers from using it.

Re:problem no 1.: lack of tutorials and beginner d

[Anonymous Coward]

Your complaint is valid for almost every open source project out there. Documentation does not exist or is out of date. Most OSS developers don't give much of a damn whether the software is documented or not. And if it is documented, it is most likely some tacked on one page afterthought called "README".

Rarest of all are requirements and architectural documents. Essentially there is no way to validate most Open Source Software because there exists no requirements or architecutural documents. Anything goes.

Q: What is this software supposed to do?

A: It does what it does.

These factors make real, legitimate quality assurance an impossibilty. At best QA on Open Source Software consists of ad hoc bug fixes and low level "lint" style syntax checks. Without requirements documents, there is no way to achieve QA in-the-large.

Re:Good user feedback...

[Rogerborg]

• If you want to switch, just do it, don't advertise it.

Good points, but as a developer, I'd appreciate a short factual note saying that a user had switched, and the reasons why. Heck, if half of my users said that they'd switched to open source solution X, I'd have to give serious thought to acknowledging that it might be a better solution, and that my time would be better spent improving it rather than pushing my solution. Sourceforge is absolutely littered with completely obsoleted projects that stagger on through ego and inertia. I'd like to see a see more project pages that say "We're all working on Project X now, and we suggest that you switch too."