In my previous two blog posts, I have talked about growing our community and communication. In this post I will be focusing on communication and how we can best improve it, and in so doing expand our community. A number of things can be done to improve our communication, some of which I laid out in previous posts. But one way or another we must improve – both within GNOME and the wider free software community.
In GNOME, as in most free software projects, the majority of communication takes place online. This in of itself, does not make it open. Many discussions take place primarily on IRC and are, in effect, private. When discussions eventually bleed over onto bugzilla and/or mailing lists, they are usually close to, or have already been resolved. The result is that most users and developers receive notice of changes only when they have already been finalized (or nearly so). Too often this is after they have been announced by a third party, or (even worse) a 4th, party such as Slashdot or Reddit.
Obviously, this is not an ideal way for any organization to project its message. The resulting fallout is generally negative, putting GNOME developers, designers and defenders alike on defense. Whats more, defensive responses are generally reactive, and are often perceived as dismissive. Of course, nobody likes to be dismissed and the result is another round of negative feedback, thus perpetuating the cycle. It is this cycle that we must break if we wish to remain relevant and respected.
Remaining relevant and respected should, I think, be a priority. In order to do so we must develop a better system to communicate what we’re doing, why it is important, and when it will occur. When we remove features, we need to explain our reason for doing so to users. For example, what was it about compact view mode that was truly harmful to Nautilus? We must also ensure that we avoid breaking API’s whenever possible. When we do so, we must explain to developers (especially those outside of our own insular community) why it was necessary, and how to ensure their work does not become obsolete. This means explaining ourselves, writing documentation and helping others whenever and however indicated.
If we continue to break API’s at random (like those in GTK+3 ), we will continue to alienate developers, and with them, users. This should be a concern, but does not seem to be for some GNOME developers. By ignoring the needs of others, we drive them away, which turns them from being supporters into detractors. When it appears that we are doing so on purpose, by breaking API’s and purposefully ensuring that extensions and themes cease to work, we anger and alienate users and developers alike, sometimes permanently.
But hope springs eternal, and change and growth for the better can (and hopefully will) occur. Primary to that is respect – for others’ work, ideas and opinions. Being open to others’ thoughts and a willingness to listen and consider outside ideas. Secondary to all of this is communication, on both sides. For those within GNOME, communicating what they are doing, and where they expect and hope to take GNOME in the future. For those on the outside, a willingness to listen, withhold judgment and avoid knee-jerk reactions. With just a bit more understanding and compassion, GNOME can continue to move forward, as a vibrant and relevant member of the wider free software community.