GNOME's image also suffers because the project fails to emphasize its cultural and technical strengths.
For instance, at the same time that GNOME 3 has been condemned by many users, the GNOME Outreach Program for Women has been so successfully revived in the last couple of years that it is now being extended to other projects. Yet this success story has received only spotty marketing efforts from the larger GNOME organization, relying instead on its own efforts for publicity.
The situation is no different on the technical level. GNOME Shell extensions were in development for almost two years before Clasen's announcement -- in fact, I wrote about how they could re-create GNOME 2 eleven weeks earlier.
Even more tellingly, the GNOME project has failed to distinguish between the GNOME Shell, the interface introduced in GNOME 3 and the underlying technology.
When people attack GNOME 3, they are generally referring to the GNOME Shell. Attacks on GNOME's utility or application are much rarer. In fact, GNOME 3, Ubuntu's Unity, and Linux Mint's Cinnamon and Mate all share the same GNOME infrastructure.
Figures are unavailable, but that probably means that while many dislike GNOME Shell, GNOME technology is probably used by more people than anything else.
Clearly, the problem is not that GNOME is doing nothing worthwhile. It simply isn't letting people know when it does.
The main message that GNOME needs to communicate is that it can listen to users and their concerns. After eighteen months of complaints about GNOME 3 with very little in the way of any response, many users believe just the opposite.
A large part of the problem is organizational. Mailing lists for localization or specific apps like the Epiphany browser are intended for user comment, but there appears to be no place for public discussion of GNOME's general design. Aside from bug reports, the same is true for testing. Although, as an upstream project, GNOME might be said to receive feedback from distributions, for the average user, communication with GNOME is difficult enough that its reputation for being unapproachable is understandable.
As for its ambassador program, presumably intended for grassroots support, it appears to have fallen inactive, with the last post to its mailing list over a year old. Yet without easily visible means for users to communicate, any claim that GNOME listens to them is doomed to be unbelievable from the start.
Besides refurbishing the means to communicate with users, GNOME also needs to show that it can manage change effectively in the future. After all, one of the main complaints about GNOME 3 is that it was too much change too quickly.
GNOME could show improved change management by adopting a number of development principles. Nobody seriously expects a free software project not to make changes, but how those changes are introduced can have significant effect on how they are received.
GNOME 3, for example, might have been better received if it had included from the start an effective fallback mode. Similarly, a menu and virtual workspace pager might have been offered as options for those who preferred to avoid the overview and to manage their desktops for themselves.
But the real concern for users is how change is managed in the future. No one expects or wants a desktop environment to be unchanging, but neither do they care for radical changes that interfere with how they work.
Faced with a similar reaction, KDE responded by rethinking how change is introduced. Its more radical changes are now introduced in side-projects and allowed to mature before being introduced into the main desktop environment. If GNOME goes ahead with suggestions for interfaces for phones and tablets, it might consider equivalent practices to ease future changes.
If GNOME took crisis management seriously, it might consider an apology -- not for the GNOME Shell as such, but for how it was introduced without preparing users for radical change, or allowing features to mature. But such a statement is probably too much to expect of anybody, especially people who have worked hard and had their efforts so heavily criticized.
Still, the steps suggested here might be enough, if only the project can make consistent and sincere efforts to implement them. Some already seem to have started happening after Lopez and Sanchez's presentation, although it can be hard for outsiders to be sure.
The greatest mistake would be for the project to approach the need for change from a purely technical viewpoint. Aside from the difficulty today of innovating on the desktop, developers often feel uneasy about marketing, and the temptation to ignore the need for it must be strong. Far easier to assume that users don't know what they want and dismiss complaints out of hand for not being expressed the way that a developer would.
With luck, GNOME will avoid such mistakes, and regain something of its former position. For all its troubles, too much of the free desktop is still depending on its underlying code and applications.
Clasen's announcement has bought GNOME some time and perhaps some temporarily relaxation of criticism. But that is all. Now, the project needs to demonstrate that it has learned something, and won't make the same mistakes again -- a process that could take months, or even years.