When I posed the question Wednesday on whether GNOME was being a good citizen within the broader open community, I also felt it necessary to push back a little for GNOME's sake.
The issue, to me, was one around sovereignty. Yes, it's important to be a good citizen, but when does GNOME (or any other project) get to establish its own path?
Speaking more specifically about GNOME, though, the problem may be a bit more complicated. The problem isn't just GNOME establishing its own destiny, but it's thinking of the GNOME as a single hierarchical entity in the first place.'
That's the take-away of an e-mail conversation with GNOME developer Dave Neary, who contacted me after reading my post last Wednesday.
"...I think a lot of the issue is that people are treating GNOME as something it's not--a hierarchical organisation," Neary wrote. "As you can see in my appraisal of GNOME for Simon Phipps's 'Open By Rule' series, the major problem for GNOME is that it is difficult to identify general leadership. I've come to realise over the past couple of days that this is a feature, not a bug..."
Wait, what? Not having a clear leadership structure? How is that a feature?
For Neary, it means working within and with a project that contains individuals with their own ideas about what should and should not be done.
"It's worth dissecting what someone means when they say 'GNOME chose not to engage' or 'GNOME rejected our efforts.' What they mean is, 'I made a proposal on a forum, and at least one person who considers themselves a GNOME developer reacted negatively, and my proposal was not subsequently adopted by the most appropriate GNOME module maintainer.'," Neary continued.
Maybe I'm getting old, but that sounds really loosey-goosey to me. So I put forth the question to Neary: "You characterize the distributed nature of GNOME as a feature not a bug, and in the purest community form, I get that. But how an such an organization reconcile that approach while working with companies or groups that are hierarchical by nature? GNOME doesn't work in a vacuum, after all, and the lack of a clear communication structure seems detrimental."
Neary's response was very interesting. Whatever your stance is on GNOME, you can't cite the guy for less-than-honest introspection:
"The kernel guys, I think, got this right early on. Their basic position is: 'If you want to work with us, you do it our way.' You send patches to the mailing list, you suffer the hail of criticism until you figure out what is expected of you. You maintain your patches until they're accepted into Linus [Torvalds'] tree, and then you're expected to be responsible for patch review to your code after that.
"If you can't handle that, the kernel doesn't want or need your help.
"GNOME, on the other hand, tried to adopt a more softly-softly approach: we had some projects (Nautilus, Evolution) which were essentially controlled by a single corporate entity. Some projects wanted to do patch review on a mailing list, others in Bugzilla. Maintainers set their own rules for their modules, for the most part. We tried to set up the foundation to give companies a way in--get in touch with the foundation, and we'll put you in touch with the right people to make what you want done possible. Commit resources and roll up your sleeves and it'll go faster.
"Unfortunately, this system has not served us well as time has marched on. Old maintainers have moved on, changed jobs, and some modules have fallen into disarray. Patch queues have built up in parts of the project. The pseudo-centralised nature of the project means that within the project there is no visibility to which modules are doing well, and which modules are doing badly. I was shocked to find a number of GNOME modules with no code commits over the past two years were still part of the GNOME release sets during the GNOME census work last year.
"KDE also has this problem--Paul Adams posted some visualisations of some KDE modules last year, to help highlight projects that needed to diversify their developer base.
"So I'm now of the opinion that the role of GNOME is to document the community processes of various GNOME modules, provide infrastructure for projects if they want it, and get back to helping people who don't understand GNOME to understand it better. By understanding the project's nature better, effecting change becomes easier (and this is what I wanted to achieve with the census).
"There will never be a GNOME architect until someone elaborates a clear GNOME-wide agenda & gets widespread buy-in for that vision--and here, Canonical has singularly failed, by focusing all their work on Ubuntu and none of it on GNOME. 'We're going to make Ubuntu better, and if some of our work is useful to GNOME, great' won't cut it."
A GNOME architect would certainly fill the bill for a centralized leadership role. But could that work? Would the GNOME community accept such a role? And if they did, who could do it? An individual? A company?
Or is such a change too big for GNOME to make?