For years, FOSS needed to catch up with development on Windows and OS X. The need was unavoidable, because FOSS started later, and, for a long time, had fewer resources than proprietary rivals.
Moreover, people can switch more easily to a free operating system if it resembles what they already know. Nor should developers waste time reinventing the order of menus in a window or the key combinations for copying or pasting.
However, imitation also has its problems. It can lead to blind copying, such as placing the main menu at the bottom left when people will find it more quickly in the top left. It also means that you are always at least a step behind, which interferes with recruitment -- after all, who wants to bother with an operating system that isn't up to date?
The truth is that, in an increasing number of areas, including the general desktop and the office suite, FOSS has already caught up with proprietary systems, or is about to do so. In some cases, such as KDE4, FOSS is actually taking the lead in experimentation. But most of the community has not yet switched its thinking from imitation to innovation, and this failure of perception risks holding FOSS back.
As Mark Shuttleworth of Canonical pointed out last summer, it is not enough to equal Apple. The goal should be to surpass it.
Any community tends to become an in-group. Consisting of networks of association that have existed for years, and because status in it tends to be based on contributions, FOSS is probably more insular than most communities. A newcomer to FOSS has to develop both a certain amount of technical expertise but also a body of largely unwritten philosophy or knowledge before they can hope to fit into the community.
All that is understandable, but it is no excuse for the undisguised impatience and scorn that many community members show to newcomers. Too often, I've seen well-meaning, if uninformed newbies lose interest in learning about FOSS because their basic questions provoked rude replies in which "RTFM" featured as a prominent comment.
Apparently, many community members have yet to realize that the average person looks for help from people before documentation, or that asking a question rather than researching a subject for yourself may be an attempt to establish contact as much as a plea for help.
Granted, not everyone is suited to tech-support. But if a code of conduct was aimed specifically at how newcomers were treated, then the community might gain a few more recruits instead of scaring them away. It would also be more in accord with free software's four freedoms and the open source definition, as a recent blog on GNUMedia points out.
FOSS began among developers, and their work remains central to the movement. But what many people haven't noticed is that the community has grown far past its origins. Especially in large projects, documenters, testers, artists, marketers and managers -- to say nothing of general end users -- have all become essential contributors. Increasingly, a FOSS software release is becoming a collaboration among people of different skill sets.
Yet, despite this change, in many projects, non-developers are given second class treatment. In a large number of cases, they cannot become full members of the project, and are not allowed to vote. If a non-developer makes a suggestion that would help the project, too often the response from a developer will be, "We look forward to your code" -- with the developing knowing very well that they are not talking to a coder.
Under these circumstances, non-developers can hardly be blamed if they lose their enthusiasm for a project. And, without them, much of the work required for a modern piece of software simply won't get done.