Questioning corporate involvement in GNOME development

Their strengths are that the GNOME packaging is roughly as good as Fedora's, they are sometimes better than Fedora at patching serious issues, and they have far superior quality-control for their updates (compared to Fedora). It is also much easier to join their community and contribute fixes or packages.

Do the Debian packagers make GNOME demonstrably worse, or are they not hiding the warts?

I don't run GNOME because it lost features I wanted and the people in the community couldn't share their creation with people who were different to them. This is the problem that the GNOME community needs to solve, possibly related to corp involvement but as likely to be entirely distinct. I would advocate more corps to get involved, but my situation is I'm put off from doing so and therefore I expect others to also be caught between needing to get involved and being rebuffed.

K3n.

Yes, that's how GNOME started to feel some time ago.

For example type-ahead find in Nautils (gone in 3.8 or so): I found out about that change after updating Fedora. Googling what the rationale is. (IIRC) one developer said (before the final Nautilus release) "don't worry Nautilus search will be as fast as the old type-ahead search".

Except it isn't for me: First due to my folder organization (which I *won't* change) I often have many folders with the same name in a subtree. And second even if the first hit is the right folder I can't navigate as fast as possible because somehow Nautilus is lagging in that case (I suspect this is because dozens of search results are displayed, some thumbnailing starts and I'm experiencing I/O waits).

Things like that really annoy me on a daily basis. That being said the Gnome Shell (for me) has more good features than bad things (workspace organization) so I'm still using it.

No, the legacy support for /etc/init.d/ and /etc/fstab doesn't count. I need to know how to make post-systemd components behave the same way pre-systemd components did after their upstream maintainers have changed the component's architecture to fit systemd's view of the world. It wouldn't be a problem if post-systemd sshd was the same thing as pre-systemd sshd, but it's very much not.

It is possible, after reading all the documentation and filling in the gaps from the systemd source code, to get the legacy behavior back; however, busy admins want documents like "how to make the new WiFi behave just like the old WiFi by editing two config files."

Well, there is another option, which is not to invent criticisms out of 'imagination', but stick to the facts. As the LWN article points out, if RH were in fact dictating GNOME development in its own interest, there would presumably be some kind of evidence of this, yet no-one seems to have provided any. The things people don't like about GNOME 3 don't seem to be things that are obviously helpful to Red Hat.

(note: I work for RH (though not as a GNOME dev), I am not at all unbiased on this. I'm still right, though. :>)

I think part of the problem here might just be that people aren't appreciating the history. Red Hat hires major contributors to projects like GNOME so they have a paycheck to work on them full time. This is a pretty established model by now, and other companies do the same thing for various projects (most obviously the kernel, where there's still a healthy ecosystem with dozens of employers involved). In the past, other companies would do the same for GNOME devs: Sun was a major employer of GNOME devs for a time, so was Novell at one time, Ximian when it was independent, and various others have contributed over the years. Since 2008-2009 or so, what's happened is all the *other* corporate sponsors of GNOME have sort of dropped out, leaving RH as the major corporate sponsor by default. In particular Sun more or less disappeared as an employer of GNOME devs when it was bought out by Oracle. RH hasn't been working on some Cunning Plan to become the major employer of GNOME devs. It's hard to see how it would be in anyone's interest for RH to pull out too, leaving very few full-time GNOME devs.

It'd be interesting to draw a graph of corporate vs. volunteer devs over time, with the companies separated. My guess is the *overall* proportion of corporate vs. volunteer contributions would be pretty consistent over time, and favouring corporate contributions - but back in the mid-2000s you'd see multiple corporate sponsors sharing the load, while from 2010 onwards you'd see mainly RH. But I don't think there's ever been a period where the majority of GNOME development was done by unpaid volunteers.

Adam addressed this adequately, but I'd like to add one thing: make it clear when you are just completely performing free-associative thought so the rest of us can have context:)

>That's laudable but you probably want some using alternate platforms just to shake out interoperability issues and have team members who are familiar with how other platforms have solved problems. You don't want to end up in an insular, but profitable, backwater where no one really knows what the state of the art is (aside from your locally generated software being "the best") because it's considered treasonous to use alternate platforms.

The goal I had in mind is so far from being the case right now that keeping an eye on other systems won't be problem unless a miracle occurs. If said miracle occurs there would still be people who need to run windows/Mac only software, in addition to "anything else". It's the "anything else" that should be oss if at all possible. That, and the amazing folks in qa should be enough to perform an adequate hybrid-dogfood.
The question of knowing what else is out there isn't a serious problem because that is something that happens now, and SHOULD continue, but this is mostly of concern to designers and analysts. It's a rare situation where you find state of the art solutions conceived/developed whole cloth from any of these platforms (Linux included), but they are still helpful to see trends and, perhaps, gaps in what solutions you provide.

>While its too late now, it would have smoothed the transition considerably if instead of a forced march to gnome-shell if it was offered as a secondary option and the traditional UI was maintained. Of course that would mean that gnome-shell would have less development resources available so it wouldn't be as polished today as it is but it would allow the end-user to have more agency which would have made them happier, usage could grow organically until the old design is deprecated because no one chooses to use it anymore. You think that we all would have learned from the KDE4 example but I guess not.

As you say, there was the issue of manpower, and how it's allocated. The decision was made, by gnome folks, to only offer the classic shell for a short period (i'm not counting the changes made to accommodate rhel7 as those are isolated). That's certainly a decision that could be questioned but I don't think it was the main reason why g3 doesn't seem, to me, to be the success that was hoped for. Again, I won't get into it here.

One further thing about the idea of RH controlling gnome.
Whitehurst gave a talk at some startup event where he mentioned gnome (well, the desktop, but really gnome) as something he wanted to get rid of early in his tenure to save money, but was told that it was important to the community. It was a cost of doing business.

Hmmm. Have you tried asking?

Have you tried user surveys?

Have you tried taking someone's complaint about something that's changed and saying "how about we find a way to do what you want and what we want?"

When people file bugs against things that change, have you tried not closing them as WONTFIX?

I've seen the GNOME developers state that they're aiming GNOME at people new to Linux, people on tablets, people coming from other operating systems: have you tried also including "people who have been using GNOME a long time" in that list?

It's admirable to say "we're aiming to reach people who aren't using GNOME yet", but how do you know what they want? Have you spoken to them? Have you got any practical evidence of what their requirements are? Have you real world case studies, rather than just the opinions of GNOME developers?

Do you know why the people who aren't using GNOME aren't using it? I.e. are you wasting your time targeting a group of people that have other barriers between them and you that you cannot remove?

And have you some kind of practical statement of how the existing users of GNOME will not lose out in the bargain?

It sounds to me like there's more problems than just "we have not a good idea [how] to figure that out" - it sounds to me like you're not actually asking how to figure it out at all.

That, to me, is arrogance.

Paul

>How do you know? The basic responses you got are because we have not a good idea to figure that out. You take this directness and see it as arrogance, while that is not the case.

Well, could you please have a look at this bug:

https://bugzilla.gnome.org/show_bug.cgi?id=705177

You where told that a certain change broke full-screen for a number of applications (GIMP being one of them), and the immediate response was that those applications should not use full-screen at all, because that use case did not match GNOME's vision). A change, by the way, that tried to solve a cosmetic issue, and did not fix it but made it even worse, in my humble opinion.

If Canonical was really about getting on the desktop, they should have grabbed System76 and set up a retail chain of their own.

This because trying to get the big brands to offer Linux options are futile, MS have too deep pockets for that to happen (the sales margins are razor thin, so they companies need the bulk discounts).

At the level of systemd/etc, there is no such thing as "wider *nix compatibility" -- every Unix, BSD, and even Linuxes were already incompatible.

Even at a higher level, often the only way to get any sort of compatibility between those environments was to install the GNU tools everywhere.

But anyway.

What is Red Hat doing specifically?

Dictating and deciding the direction of the project to their own benefit while treating community contributions as second class citizen.

Why are those things bad?

Oppression while sending false sense of freedom in any shape or form is bad.

If you dont understand why that is there is very little thing I can help you in that regards.

When did they happen?

This is not one time thing, this has been happening from day one in Fedora and is happening today.

What has happened since?

People stopped contributing to the project and the ecosystem in whole.

Are other organizations behaving in the same way?

On a distribution level I dont think anyone can top Red Hat in that regard but I'm not familiar with other distributions and their community since I been very loyal contributor to the Fedora community and Red Hat for the past 8+ years then I got hit harder then usual by reality how Red Hat operates.

I suspect Novell is second to Red Hat in this regards with OpenSuse followed by Canonical and Debian but basically you will see this pattern forming anywhere where there is an enterprise distribution built upon community one or an enterprise application like zenoss,nagios etc. with an community. ( As in you have two product the enterprise one and the community one ).

What were their consequences?

These things usually end with a divorce ( the exception being those that do not have direct single enterprise counterpart ) with the best case scenario that contributors fork off or continue contributing elsewhere in the ecosystem and the worst case scenario they stop contributing altogether to the ecosystem in whole.