The thing is, that "more code" doesn't just appear on its own. It takes time, skill, and desire by the code writers, and for more than a few projects, the actual ideas behind the code are not viewed as in line with the project's goals. Does that sound familiar? :-)

Of course such a solution might not be easy and no, the code does not magically appear.

As long as free/libre developers continue to think like developers rather than as users, these kind of "conflicts" will continue. This is the "VCR blinking clock" syndrome. I've done enough small-scale programming and tech support to have experienced the developer world and I have been a user for almost 30 years. On a regular basis I work with people who are not computer savvy and are not geeks. I have observed these people a long time. Add more than two decades as a tech writer using computers as a tool and I understand usability better than many people.

My programming projects and tech support for other people were steered by the users, not by me. I often have shared with people that programming software to provide the wanted or needed functions usually is straightforward. Making the program robust and actually usable by most people is where the challenges arise. The free/libre developers remain trapped in their "scratch my own itch" mentality. That attitude is fine for some software projects but not for tools intended to be used by thousands of people. I would like to see free/libre developers make lots of money, but they need to shift their thinking for that to happen. They need to scratch the itches of other people.

During my last contract project I was required to use some in-house software. The software was atrocious. The software worked fine for the person who developed the software but almost nobody else could use the software without a lot of four-letter words. The developer understood the basic needs and function of the tool but had no clue about usability. The project manager was a complete institutional man and would not do anything about the problem --- he did not want to "rock the boat." The software was awful. Hint: one of the tools was a database that did not index tens of thousands of files. Hint: the tool was on its own file server behind the corporate server 2,000 miles away with no local mirror, no RAID, no backup server, and written with a software toolkit that was obsolete a decade ago. The tool worked for the developer 2,000 miles away but not for anybody else.

I envision a day when desktop computers are usable by all people and not just the geeks. That day has not yet arrived. That day will arrive when, as noted by Andrew Tanenbaum, computers are built without a reset button. After almost 30 years I've grown weary of developers being defended. They are hired to produce usable products. Require them do their job and start producing usable products. A significant number of free/libre developers now work under corporate umbrellas, so there is no excuse anymore. The first and foremost goal of any software product intended to be used by thousands of people is to make the product usable.

I'll answer your question with a question: Who drives these alleged project goals --- a handful of skilled developers or tens of thousands of end-users?

Again, Thank you very much.
I just noticed The GIMP 2.6.4 was released today. If I wanted to compile it to run on Slamd64 (when 12.2 becomes available), how would I go about it? Broad question I know. I've ran many Slackbuild scripts, but I don't see one for The GIMP in their repository.
Many Thanks!

A better solution, I think, would be to find out why some users prefer the old interface, why some users prefer the new interface, and design a new one to incorporate the advantages of both.

As long as you are talking about free software which is being developed by people who do not get any money out of it, the answer is: the handful of skilled developers determines how the software is written and works. It is their prerogative! If you think differently, I will just tell you that you get what you pay for.

If on the other hand you talk about free software which is being developed by people who are being paid for this by their employer (like most of the Linux kernel team, samba team, gnome and kde teams etc...) the influence of the intended users of their software will likely be a lot bigger.

Eric

Not always. Look at inkscape project driven by community.

Sure. They are free to scratch only their own itch and that is indeed their prerogative, but with that kind of thinking free/libre software will continue to be less competitive and will remain labeled geek-ware. As I said previously, as long as free/libre developers continue to think like developers rather than as users, these kind of "conflicts" will continue. Whether they get paid is irrelevant.

I don't have a problem with Slackware being labeled as geek-ware. Slackware is designed/developed for a certain sub-set of Linux users, that is, users who enjoy rolling up their sleeves and getting into the nitty gritty of system configuration. I seriously doubt that Slackware will ever become mainstream enough for casual computer users. That is okay.
There are many excellent versions of Linux that are designed for computer users who want their computers "to just work." To me that is the beauty of open source software. Use an OS that works for you.
Having said that I think that the Slackware developers do listen to their user base. Patrick stays true to the Slackware philosophy of keeping Slackware stable, robust, and secure.

Unless developers are users. But this happens rarely.

Becoming mainstream is easy with lots of gui tools to configure the system and mega-script to setup everything from user friendly interface (it was posted somewhere, iirc).

Personally, I think you don't blame lfs for being from scratch. This way you can't blame Slackware for being like this cause this is one of the things which makes it different. That would be strange coming to ubuntu forums and asking make it like gentoo.

Of course. That is why I wrote that it is the prerogative of (unpaid) developers of free software to determine how their software evolves. They can decide that the community should have a large part in the development, and that is fine. You usually find that only a core team has commit rights to the source code repository in order to maintain code quality. Software will only get better with an active community doing the testing and providing usability feedback and bug reports. Even then, the developers may have an architectural design for their software that they are not willing to stray from, so not all user contributions would automatically be accepted or acceptable.

There is however a difference between contributing good ideas and good code and substantiating this with a proper reasoning why the contribution should be accepted, and demanding that changes to the software should be made simply because end users want it.

It is my opinion that if you use free and open source software, you have to be prepared to give back to the community - in any form. Woodsman for instance does this by maintaining a set of well-written Slackware oriented documentation. Another option would be to contribute translations of software into your own language. There is a variety of options available to give back to an open source community. Simply demanding that free software should bend to your wishes is not how it works.

Some see arrogance in developers' responses, where I see care about the product they develop. Others think that developers should jump through hoops in order to satisfy incompatible requirements and this is what I call ignorance.

Going back to the topic of Slackware, there is a slight difference because strictly spoken it is not a software product, but rather a collection of software products with Patrick adding the glue that makes it boot and work on your computer. But if Slackware's maintainer would not listen to the end user community there would not be a HAL in Slackware, nor DBUS, nor bluetooth support, et cetera. It is just that there is a philosophy behind Slackware that ensures that certain things will not happen to it. It is what makes this distro stand apart from the others. It boils down to "lean and transparent" (some would call this "imcomplete" and "not of this age").
This is what makes Slackware so easy to adapt and customize. If you want change it is not terribly hard to do the changes yourself (or with a group of people). If you think your enhancements should become part of Slackware, then by all means go for it, and convince Pat of this. But you need to be prepared to be turned down even with a good idea. There is only so much change that can go into Slackware, it being primarily a one man mission. Even with a group of dedicated but volunteering people assisting him.

Eric

I never mentioned Slackware in this recent series of discussions. Nor had I any intention of implying as such. I was writing generically.

Regarding Slackware, I participated in testing the last three releases of Current, not to the extent of the inner core team, just in my own way, and Pat and the team are responsive to comments and suggestions.

GIMP is a good example of needing to be user-driven and not developer-driven, regardless of monetary remuneration. GIMP is always in the free/libre flagship software list. GIMP developers should not be scratching their own itch over the demands of many users. I'm not blind to the challenges --- been there done that at my own level. Sometimes the demands of end-users are ridiculous. Many free/libre users do not realize that the free/libre process is driven by participation, not demanding and whining. Yet the user interface is too fundamental an issue to be deemed ridiculous. Many people dislike floating toolbars and palettes. Some like them. Pleasing both crowds is impossible. Hence my original post about providing both interfaces --- regardless of the challenges.

OOo is another flagship example that should be user-driven. I'm still waiting for a true draft mode in Writer (a.k.a. Normal View in Word). This feature has been requested for years by many users and ignored or excused as "technically too difficult."

Fundamentals. Think like a user and not like a developer. I'm not discussing Slackware here. Slackware is, as Eric noted, focused toward a specific type of user. GIMP and OOo are intended for all users. They are intended to be mass-market products. There is a significant difference there.

My mistake. Apologies! It serves me right for not following this thread a bit more closely.
This is an excellent discussion, I am enjoying it immensely.

Another operating system that I enjoy playing with is OpenBSD. Every now and then, someone complains on their mailing lists that OpenBSD does not have feature X or application Y. Invariably, the response is, essentially, that the OpenBSD developers make the operating system for themselves. If you enjoy using it, great. If you have a contribution to make, then send in a diff. Otherwise, just don't use it. They are not out seeking users and don't plan to stray from their overall design goals. I think Slackware is similar.

Slackware is not for everyone. Patrick and the Slackware team develop the distribution in the way that they choose. If you enjoy using it, fantastic. If a particular user feels it doesn't work for them, then fine -- they should use something that does work.

Thanks for the great post, Eric. I agree with every word.

Please keep in mind that the subject of this topic is "Slackware 12.2 is released Officially" and try to stay relatively on-topic...

Eric

I'm a FreeBSD user and enjoy learning how to use it. I read many similar complaints at the FreeBSD forums, that FreeBSD is hard to use and it should include GUIs. That is why there are many forks in the BSDs like PC-BSD which is more user-friendly and is an exceptional OS.
Yes. Thanks for the excellent post, Eric!! I am in total agreement.