GNOME module list suggestions

allanday commented 3 years ago

Which modules are included in the definition of GNOME is one of the trickiest aspects of measuring activity in the project, and is something I've struggled with myself in the past. That said, looking at the list of modules, I'd suggest a few changes:

Core dependencies

The list includes a number of core dependencies which, while they are vital and important to GNOME, have a significant life beyond the project. This includes:

gtsreamer
wayland
NetworkManager
cairo
pipewire
ModemManager

The concern here is that a project like gstreamer or wayland could skew the results.

My suggestion would be to remove these modules from the analysis, and possibly conduct a separate analysis for this set of modules.

There are a bunch of libraries which have a similar status, including:

grilo
lvfs
fwupd
flatpak

It might be good to include those in the "core dependencies" group.

Edit: actually, there's a huge list of additional core dependencies we could consider. Certainly udisks2 and upower should be in there. I also wonder about buildstream, cups, WebKit, meson...

Questionable apps

The module list includes a few apps which are somewhat questionable.

The first is f-spot and banshee. These were never 100% official, which is maybe fine if the goal is to have a somewhat fuzzy definition of GNOME based on the main areas of activity and interest in the community as opposed to a strict product definition.

Of course, if we go down that road, then we might also ask whether other apps should be included, like shotwell, geary and polari. (shotwell is a bit tricky because it became an Elementary app at some point.)

One app that I would argue fairly strongly to remove is GIMP and its associated modules (gimp-web and gegl). While GIMP has a historical association with the GNOME project it is fairly independent and has been for some time.

Missing modules

From a cursory inspection, these seem like obvious omissions which it would be good to include:

clutter
polari
gnome-builder
simple-scan
sushi
dconf-editor
gnome-online-accounts

@felipeborges @neilmcgovern

hpjansson commented 3 years ago

Thanks for the detailed feedback! I was indeed trying to cast a wide net. Regarding missing modules, gnome-online-accounts seems to be there, and clutter history was merged into mutter's if I'm not mistaken, but it looks like I missed the others on your list. At a guess, this will have an effect on the commit counts, but probably not much in the active authors count, as there's a lot of developer overlap. I feel extra bad about missing shotwell, geary, polari and gnome-builder!

I like your suggestion for a split -- if I'm understanding correctly, we'd end up with three categories: "F/OSS desktop plumbing", "GNOME platform/infrastructure/docs" and "GNOME/GTK flagship applications". Then we could get a better fix on how the platform proper is doing, and expand the plumbing and applications lists a bit. I guess minimum criteria for the latter could be "more than $N LOC, relies on GTK widgets". Or maybe instead of/in addition to LOC we could select by number of downloads on Flathub, or distro numbers (Debian popcon?).

As a footnote, I guess the questions I'd like to answer are along the lines of:

How many people are highly experienced in developing and applying GNOME technologies?
Is that group likely to grow or shrink?
What is the churn rate like, and is experience being transferred well?
Are there any signs of stagnation or burnout in general?
How have past group decisions affected the project and the group itself?

I was interested in the C# projects because they were developed by people with vast GNOME experience and intended as desktop centerpieces, but the technology occupied an awkward space and was eventually rejected. There have been other projects that met with dead ends too, and I thought it made sense to include them because I see it as part of the group effort. Similar things happen within modules when branches fail to be merged or code is rewritten/retired.

federicomenaquintero commented 3 years ago

If I may chip into the bikeshed...

Maybe aggregating all the jhbuild modulesets over time would be interesting. I saw that gnome-panel is missing, which was a big part of the action in GNOME2.

I like the idea of splitting by categories! I suppose you'll find much more drive-by contribution in applications than in the core platform, but who knows.

allanday commented 3 years ago

I like your suggestion for a split -- if I'm understanding correctly, we'd end up with three categories: "F/OSS desktop plumbing", "GNOME platform/infrastructure/docs" and "GNOME/GTK flagship applications".

I was imagining two categories: "GNOME" and "core dependencies". The primary motivation for that is to remove any skew from projects that are (semi)independent from GNOME and whose "health" might not reflect the health of the GNOME project itself. For example, I don't think contributions to GStreamer, which is used far more widely than GNOME and is fairly independent, can be simply interpreted as commits to the GNOME project.

This isn't to say that these core dependencies aren't important to GNOME, or that contributions to them aren't relevant to us, which is why I'd analyse them separately.

To me, creating categories for platform/infrastructure/docs versus GNOME/GTK is potentially interesting, but has a different goal. My suggestion is intended to ensure validity of the analysis.

(Side note: if we were to examine levels of contribution across modules - super interesting! - I would personally be more interested in identifying categories empirically rather than a priori. Which modules are most active over time? Which ones have low/high contributor turnover? etc, etc.)

(Edit: also on per module contribution levels - it would be really interesting to analyse which modules are primarily supported by which companies. You might well see that some are primarily developed by one company, whereas others have shared support.)

hpjansson commented 3 years ago

Fair enough. GStreamer felt GNOME-y to me because of its strong GLib tradition and usefulness to the desktop, and the developers sometimes show up at GUADEC too.

I'm toying with the idea of a "plumbing" category that could serve the function of "core dependencies" for more DEs than just GNOME. May be a pipe dream though. It depends on what other projects would consider core and not (e.g. KDE vs. Qt).

alatiera commented 2 years ago

if I may also chime into the bikeshed.

I find the question about important underlying libraries very interesting. With my gstreamer hat on I could tell you that intersection between a gst and a gnome developer is a sizable group of people, but there are also a lot of activity that comes from other sources. The way that activity would be counted, if at all, would be very interesting, do we identify the people with strong associations to gnome and group the rest separately? Should those projects get a plumbing category of their own? Do we ignore them for now to avoid the hassle?

I think those are similar to other sizable projects, like mesa, systemd, pulse, webkit, NetworkManager, wayland family, xorg too, or probably most of the projects hosted on freedesktop.org infrastructure. We will likely find former or still active gnome people involved with the majority of them and being heavily invested into them.

There's also another category of fd.o projects that exist currently where they are developed mostly by gnome people, but given their nature that will likely change in the future are they are meant as generic infrastructure. What comes to mind is things like bolt, upower, accountservice, pkg-config, libfprint, plymouth, and probably more of them.

I don't really know how to conclude this comment other than, dumping theses shower thoughts here. But I really appreciate the effort that has been put into these analytics/metric and its very valuable! Thank you!

hpjansson / fornalder