The YaST Team just finished the last sprint before the Christmas break of this convulted 2020. So let’s start the festivities by celebrating what we have achieved in the latest two weeks. That includes:

• Several additions to AutoYaST
• Better management of required packages
• Usability improvements in the registration process
• Drop of the SysVinit support
• Translation infrastructure for the wicked Cockpit module

Let’s go into the details.

You may remember that we recently introduced support in the YaST Partitioner for tmpfs mount points and for Btrfs subvolume quotas. Now those technologies have been incorporated to AutoYaST. See this pull request for some overview of the tmpfs support or this other one if you want to check the full documentation. If you are more curious about Btrfs subvolume quotas, check this pull request for some general description with screenshots or the documentation one for more comprehensive information.

We also improved how YaST manages the packages to install in order to support the different storage technologies and file systems. During installation, YaST now makes a difference between optional and mandatory packages, which implies it will not longer force you to install ntfsprogs just because there is a leftover NTFS partition somewhere in the system. Moreover, in an installed system YaST only forces installation of those packages strictly needed to perform the Partitioner actions, reducing to a minimum the number of repository refresh operations triggered by the Partitioner.

Regarding the registration process during the installation of SLE (SUSE Linux Enterprise), we have been working in a couple of fronts:

• More informative and up-to-date information about the implications of skipping registration when performing a so-called online installation.
• Some experiments (still under discussion) regarding the layout of the registration screen.

In a more general scope, we removed some bits of code in YaST that were still trying to modify the obsolete /etc/inittab file. See the announcement in the yast-devel mailing list about the definitve drop of support for SysVinit.

Going beyond YaST itself, we added internationalization support to our Cockpit module for wicked. The corresponding project is now available in the openSUSE Weblate instance and all the automation is in place to ensure all the translations contributed by our awesome volunteers are incorporated into future releases of the module.

As mentioned at the beginning of the post, this was the last development sprint of 2020, which also means this will be the last blog entry from the YaST Team this year. We will restart the usual development (and reporting) pace after the Christmas and new year season. So there is only one more thing left to say - see you in 2021!

Me está gustando esto de compartir mi pantalla siguiendo la iniciativa #viernesdeescritorio y gracias a la energía de Lina castro (@lirrums). Así que, de forma extraordinaria, añado por segundo mes consecutivo una entrada a la serie «Mi escritorio», en la que comparto en el blog el aspecto de mi ordenador. Espero que mi escritorio Plasma de Diciembre 2020 os guste.

Mi escritorio Plasma de diciembre 2020 #viernesdeescritorio

Esta va a ser la séptima vez que muestro mi escritorio Plasma 5 en público. Respecto al mes pasado quiero comentar que sigo utilizando Latte Dock y cada vez más acostumbrado al entorno oscuro.

Como es habitual, la captura está realizada sobre mi portátil Slimbook Pro de 13 pulgadas, el cual tiene instalado un KDE Neon con Plasma 5.20.3.

Utilizo el motor de ventana Kvantum, lo cual le confiere un aspecto muy particular, con unas transparencias muy elegantes. Me quedaba cambiar los iconos y ya lo hice, ahora tengo utilizo Papirus-Dark.

El resultado de mi escritorio de diciembre de 2020 es un escritorio más vistoso, e incluso diría recargado que queda genial para estos días pre-navideños e ideal para que mis alumnos vean la capacidad de personalización de Plasma, estos días que por diversas razones mi portátil es parte fundamental en las clases.

En definitiva, este el el resultado. Pincha en la imagen para verlo un poco más grande.

Las características del escritorio son las siguientes:

Gestor de Ventanas: Kwin (he probado con Wayland, se ve incluso mejor pero tiene un bug en Kontact me imposibilita utilizarlo)

Look and Feel: Otto de Jomada (uno de los grandes diseñadores de temas para Plasma)

Estilo de Plasma: Otto-not-rounded

Fondo: solamente sé que se llama cusd.

Estilo de aplicación: Kvantum

Iconos: Papirus-Dark

Plasmoides:

• Barra de tareas: Latte dock centrada y que se ocultamiento automático y que contiene, de izquierda a derecha, lanzador de aplicaciones Kickoff, gestor de tareas solo iconos (que ahora es el por defecto en Plasma), Let is snow y bandeja de sistema.
• Reloj digital: Digital Clock BeClock Style
• Daily Forecast: para tener la información meteorológica.
• Let is snow: un plasmoide visual que añade nieve sobre nuestro escritorio y del cual hablé hace poco tiempo.

この記事は openSUSE Advent Calendar 18日目です。 残り、あと少しですが、まだ埋まってなく3年連続の完走がピンチ。みなさんご協力下さい。

この内容は小江戸らぐのオフな集まり2月と、オフだけどオンライン開催だった5月の発表内容でもあります。

ことの始まり

この春、ファイルサーバーを組みました。これまで、写真等の大きめのファイルはデスクトップに置いていましたが、タブレットやスマフォを使用しているとデスクトップを起動しないこともあり、アクセスするにはちょっと不便でした。かといってクラウドに上げるには容量が大きいのが現状です。

このとき、電源の故障で引退した、ちょっと古いけどまだ使える一式（Socket FM2 の M/B, AMD A4-5300 APU, DDR3 8 GBメモリ）があったのと、鹿さん から、使わなくなったファイルサーバー用の MiniITX ケースを頂いたので、これでファイルサーバーを組んでみることにしました。

RAID カード調達

HDD は NAS 用のものを適当に買うとして、1度はRAID 5 や 6 で組んでみたい！ということで、RAID カードを探しました。一般のご家庭（誤変換）では、数万円クラスのカードを使っているかと思いますが、この「ありあわせ構成」には不釣り合いです。安く入手する方法としては、ヤフオクなどでサーバーから抜き取ったものを探す手がありますが、あまりに古いと EFI に対応していなかったり、4 KB セクタや 2TB の壁にあたる可能性があります。また、中古品はキャッシュ保護用のバッテリーが死んでいる可能性もあります。

そこで今回は eBay で3世代前の Adaptec ASR-71605 の新古品を買ってみました。キャッシュ保護用のコンデンサ付き、送料込みで 8500円くらいでした。ドライバはカーネルに入っているのですぐに使えます。

意外と高かったのがケーブルでした。Mini SAS HD から SATA ×4にするもので、Amazon で 2500 円くらいでした。

OS インストール

セットアップに困ることはないはずが、openSUSE 15.1 をインストールすると、なぜかディスプレイドライバが固まります。いろいろ試したところ modeset ドライバを ACPI が有効な状態で使うとダメなようです。今回はディスプレイはほとんど使わないので nomodeset を起動オプションに追加することで回避しました。（modeset ドライバだと、コンソールの解像度がディスプレイにあわせて変わるので良いのですが…）

ファイルサーバーの設定

Samba は入れるだけです。とっても簡単ですね。

Btrfs にしてスナップショットを取るようにしました。このあたりはOSCのスライドや Geeko Magazine を見てください。

iSCSI サーバーは4月に書いた別の記事で。

バックアップの設定

重要なディレクトリを選んで USB 接続の HDD に1日に1回、Snapper の最新スナップショットからバックアップを取るようにしました。単純に rsync でコピーを取ります。Btrfs のバックアップといえば、ファイルシステムレベルで差分転送をできる btrfs send があります。しかし、ファイルシステムが壊れてしまった場合に、btrfs send を行うとバックアップも壊れる可能性があるのではないかと考え、今回は使用しませんでした。

タイマーとスクリプトはこのような感じです。タイマーの時間は Snapper の実行中にならないように気をつける必要があります。

backup-to-usb-disk.timer

[Unit]
Description=Back up files to USB disk daily

[Timer]
OnCalendar=*-*-* 6:20:00
Persistent=true

[Install]
WantedBy=timers.target

backup-to-usb-disk.service

[Unit]
Description=Back up files to USB disk

[Service]
ExecStart=/usr/local/sbin/backup-to-usb-disk.sh
Type=oneshot

backup-to-usb-disk.sh

#!/bin/bash

set -e

if [ ! -f /var/backup/backupdisk ]; then
    echo "Back up disk is not found"
    exit 1
fi

# home
snapshot_root=/home/.snapshots

cd $snapshot_root
latest_snapshot=`ls -1 | grep "[0-9]*" | sort -nr | head -n 1`/snapshot/
echo "creating back up of /home/.snapshots/$latest_snapshot"

if [ ! -e $latest_snapshot ]; then
    echo "Snapshot directory error"
    exit 1
fi

target_dir=/var/backup/home/

rsync -va --delete $latest_snapshot $target_dir

様子見中

Snapper が走る時（おそらく）に btrfs-cleaner がかなり CPU を使うので、試しに Quota 機能を無効にしています。

おわりに

簡単にではありますが、ファイルサーバーを構築したときのいろいろを紹介しました。このファイルサーバーでは、先日書いた Spotify クライアント も動いています。新たな活用を始めたら記事にしたいと思います。

La pasada actualización de las aplicaciones de KDE de diciembre nos ofreció interesantes nuevas funcionalidades. En el artículo del anuncio ya hablamos largo y tendido de las novedades de Kontact, también hemos hablado de Dolphin, el explorador de archivos, y de Konsole y Spectacle, y ahora tocan las novedades de Konversation de diciembre de 2020. Esto no para, esto es KDE!

Novedades de Konversation de diciembre de 2020

A pesar de que poco a poco Telegram o Matrix va ganando adeptos en el tema de conversaciones en forma de chat entre los usuarios no hay que olvidar que el ecosistema KDE tiene una aplicación propia para de chat IRC llamada Konversation.

Esta aplicación goza de muy buena salud y se une al servicio de lanzamientos habitual , añadiendo un buen número de nuevas funcionalidades, entre las que destacan las siguientes:

• Konversation permite ahora la descarga de temas de iconos para alias desde store.kde.org, la página que proporciona novedades visuales a casi todas las aplicaciones KDE.
• El historial del canal se puede borrar para proteger la privacidad.
• Las capacidades de las que dispone el servidor se muestran al conectar.

Mejoras en los protocolos de comunicación

También es interesante destacar las mejoras en un buen número de técnicas del protocolo que consiguen que la comunicación sea más fluida y segura:

• El protocolo IRCv3 se ha mejorado con el uso adicional para la negociación de capacidades v3.2.
• Konversation usa ahora mecanismos de autenticación SASL en CAP LS.
• Se añade un marcador de fecha a la primera línea al cambiar de fecha en caso de que la fecha no se incluya en la marca de tiempo.
• Konversation sigue el estándar para el manejo de cadenas de texto cuando envía la orden PASS.
• Se ha añadido la capacidad znc.in/self-message.
• Se han desactivado las peticiones WHO para los servidores de twitch.tv.

Más información: KDE

Veamos cómo podemos generar códigos Qr desde nuestra términal de GNU/Linux sin necesidad de instalar nada

A veces queremos compartir un texto o un enlace entre nuestro equipo y nuestro teléfono móvil. Veamos cómo hacerlo generando un código Qr desde la terminal de nuestra distribución GNU/Linux para después escanearlo con nuestro teléfono.

Para hacerlo no es necesario instalar nada. Simplemente utilizar un servicio web mediante la herramienta curl al que le pasamos un texto o un enlace.

Para generar nuestro código Qr podemos ejecutar cualquiera de estas dos acciones en nuestra terminal:

Y se nos mostrará el código Qr de esta (añorada) url o de aquella que queráis, pudiendo también generar un código de un texto, etc.

También podemos generar un código Qr fácilmente desde el navegador añadiendo qrenco.de/ delante de la url en la barra de direcciones.

Ya veis que es un proceso muy sencillo. Y además el código está disponible para poder revisarlo.

Enlaces de inteŕes

• http://qrenco.de/
• https://github.com/chubin/qrenco.de

Five openSUSE Tumbleweed snapshots have been released since last Friday.

Snapshot 20201215 is the latest update to arrive in the rolling release. The snapshot updated KDE Frameworks 5.77.0 and offered a significant amount of bug fixes and additions for the 83 addon libraries; the Breeze Icon package added an edit-move action icon, the Attica package fixed a crash and KDeclarative relicenses files to the LGPL v2 or later. Both the KIO and Kirigami packages had extensive work done; KIO cleaned up dead code and now requires Qt 5.13. Kirigami fixed rendering borders to the proper size and also made a fix for low power mode. openSUSE’s autoyast2 4.3.64 package added support for Btrfs quotas. The default window sizing was fixed in an update of gnome-tweaks 3.34.1. Location-aware applications will notice a fix for Wifi crashes in the 2.5.6 geoclue2 package. Some obsolete settings were removed from the 4.3.6 yast2-security package and text editor vim fixed the CTRL-Z behavior.

The smallest snapshot of the week was 20201214. The lone Japanese package man-pages-ja provided nearly a year’s worth of updates to version 20201115.

Some GStreamer packages like gstreamer-devtools and gstreamer-editing-services updated to version 1.18.2 in the 20201213 snapshot. KDevelop5 5.6.1 provided some small performance improvements and a set of oddities were fixed with initial parsing of project files, The Linux Kernel 5.9.14 provided serval USB serial fixes as well as Advanced Linux Sound Architecture fixes. The only major update to arrive this week in Tumbleweed was an update to xapps 2.0.0, which should benefit Cinnamon, MATE and Xfce users. Document viewer xreader 2.8.0 added an issue with the Tab key toggling checkboxes and moved the new sidebar button to be part of the navigation group.

GStreamer had various stability, performance and reliability improvements in its 1.18.2 release, which fixed an MPEG-TS timestamping regression when playing DVB streams, that arrived in snapshot 20201212. Firmware updater package fwupd 1.5.3 added the serio->firmare_id for the UDev device manager. A minor release of systemd 246.7 had some udev renaming options made; a full list of changes can be found here. Support for Python 3.5 was removed in the python-cryptography 3.3 package and libzypp 17.25.5 fixed the update of GNU Privacy Guard keys with an elongated expiration date. The GNOME desktop’s indexing and search provider tracker 3.0.2 improved the turtle parser and made the UPDATE parser tree processing iterative rather than recursive.

The 20201211 snapshot kicked off the week with the 6.1.16 maintenance update to virtualbox, which had a workaround to improve resizing of 32-bit VMs with the VMSVGA graphics controller, and it does not try to use RandR version 1.3 due to bugs causing the X server to hang. The 5.2.0 machine emulator version of qemu has a new KVM feature that improves the handling of asynchronous page faults, and new arm boards mps2-an386 (Cortex-M4 based) and mps2-an500 were added. The qemu update also has RISC-V improvements for the Ibex (OpenTitan) Platform Level Interrupt Controller.

Kate es el editor de textos avanzados de la comunidad KDE y ha cumplido 20 años este diciembre de 2020

Un 14 de diciembre del año 2000 un joven desarrollador de 18 años llamado Christoph Cullmann, enviaba un correo a una lista de correo al responsable de Kwrite para informarle de que estaba trabajando en una interfaz MDI Kwrite, que más tarde sería Kate.

Kate (KDE Advanced Text Editor) empezaba así su andadura hasta convertirse en lo que es hoy en día. Un gran editor de texto con muchos complementos y funcionalidades, que lo hacen muy útil a la hora de editar textos.

En todo este tiempo han sido muchas las personas que han colaborado de una u otra manera en desarrollo del editor o con herramientas externas que utiliza el propio editor.

Y sigue siendo una herramienta con un gran desarrollo destrás, no hace falta más que ver que en el último mes, se han aceptado:

• 115 parches para Kate
• 41 parches para KTextEditor
• 113 parches para KSyntaxHighlighting

Y también existen:

• 172 errores abiertos
• 120 “deseos” de nuevas funcionalidades

Esto último también da cuenta de que hay muchas personas que utilizan Kate y se preocupan de reportar y de pedir uevas funcionalidades.

Cuando no uso Vim, Kate es el editor de texto que utilizo cuando quiero usar un editor con interfaz gráfica. Además también es multiplataforma, por lo que en mi portátil del trabajo con Windows, también lo tengo instalado.

Y por el blog son varios los artículos y tutoriales que he dedicado a esta gran herramienta:

• https://victorhckinthefreeworld.com/?s=kate

Pero echemos un vistazo a cómo ha evolucionado la interfaz de Kate en estos 20 años de historia.

Enhorabuena al proyecto y que siga muchos años más ofreciéndonos una alternativa de calidad y software libre.

Enlaces de interés

• Anuncio oficial de los 20 años de Kate

私はKubicでKubernetesを構築しているのですが、Kuibcをアップデートしてkubeletのバージョンが1.19に上がったはずなのにもかかわらず、kubectl get nodeでずっとバージョンが1.18となっていて悩んでいました。

結論

/etc/sysconfig/kubelet に設定されている KUBELET_VERを、1.18から1.19に変更する

調査

パッケージを確認

まず、パッケージがなんのバージョンが入っているかを確認します。

kubic1-host:~ # zypper se kubelet

S  | Name                          | Summary                   | Type
—+——————————-+—————————+——–
i  | kubernetes-kubelet            | Kubernetes kubelet daemon | package
i  | kubernetes1.17-kubelet        | Kubernetes kubelet daemon | package
  | kubernetes1.17-kubelet-common | Kubernetes kubelet daemon | package
i  | kubernetes1.18-kubelet        | Kubernetes kubelet daemon | package
i  | kubernetes1.18-kubelet-common | Kubernetes kubelet daemon | package
i+ | kubernetes1.19-kubelet        | Kubernetes kubelet daemon | package
  | kubernetes1.19-kubelet-common | Kubernetes kubelet daemon | package
  | kubernetes1.20-kubelet        | Kubernetes kubelet daemon | package
  | kubernetes1.20-kubelet-common | Kubernetes kubelet daemon | package

　どうやら、1.17、1.18、1.19、と、いろいろなバージョンが入ってるようです。

今見たら、1.20も入ってますね。

使ってるバイナリを確認

kubic1-host:~ # type kubelet

kubelet is hashed (/usr/bin/kubelet)

ふむふむ。/usr/bin/kubelet、ですね。

こういう実行ファイルはスクリプトの場合があったりするので、種別を調べてみます。

kubic1-host:~ # file /usr/bin/kubelet
/usr/bin/kubelet: POSIX shell script, ASCII text executable

なるほど、スクリプトっぽいですね。

中身を確認します。

kubic1-host:~ # cat /usr/bin/kubelet
#!/bin/sh
# Loader Script for Multi-Version Kubelet arrangement introduced to openSUSE in March 2020
source /etc/sysconfig/kubelet

if [ -z “$KUBELET_VER” ]       
then
  echo “ERROR: KUBELET_VER= not defined in /etc/sysconfig/kubelet”
  exit 1
else
  /usr/bin/kubelet$KUBELET_VER “$@”
fi

どうやら、/etc/sysconfig/kubeletの値を参照しているようです。こちらを確認してみます。

kubic1-host:~ # cat /etc/sysconfig/kubelet
KUBELET_VER=1.19
KUBELET_EXTRA_ARGS=”–container-runtime=remote –container-runtime-endpoint=unix:///var/run/crio/crio.sock –runtime-request-timeout=15m –c
group-driver=systemd -v=2 –runtime-cgroups=/systemd/system.slice –kubelet-cgroups=/systemd/system.slice”

なるほど、KUBELET_VERが定義されています。nodeのバージョンが低いときは、ここが1.18となっていましたので、それを1.19に更新しました。

それからKubernetesを起動すると、見事バージョンが1.19にあがってました。

今なら1.20に上がる予感・・・・

メーリングリスト

最近忙しいこともあって、なかなかメーリングリストなどの情報源にあたれず・・・もしかしたら、こういったことはとうに情報共有されていたのかもしれません。また、この設定がKubic独自なのか、一般的なのか、といったことも追いきれておらず。追って調査したいと思います。

そもそもの使い方

アップデートで使い続けるのではなく、折を見て最新プリメイドイメージに乗り換えていく運用が今っぽいのかも・・・・・

La pasada actualización de las aplicaciones de KDE nos ofreció interesantes nuevas funcionalidades. En el artículo del anuncio ya hablamos largo y tendido de las novedades de Kontact, y ahora toca las novedades de Dolphin de diciembre de 2020, que son muchas muchas y variadas y que mantienen en todo lo alto este explorador de archivos.

Novedades de Dolphin de diciembre de 2020

La evolución continua y Dolphin, el gestor de archivos y carpetas de KDE que no deja indiferente a quien lo utiliza, llega con varios cambios en la interfaz de Dolphin para facilitar la navegación por los dispositivos de almacenamiento y los documentos, fotos, canciones y directorios.

De esta forma ahora, la barra de direcciones de Dolphin está ahora en la barra de herramientas con lo que se optimiza el espacio y, en el modo de Vista detallada, se puede definir el tamaño para incluir todo en la carpeta, incluidas las carpetas anidadas dentro de la principal.

Además, debido a un cambio en Frameworks, el motor de todo el ecosistema del Software de la Comunidad KDE, el panel Lugares de Dolphin, de los diálogos de archivos y de otros sitios más, incluye ahora entradas para las carpetas Música, Imágenes y Vídeos de forma predeterminada.

Por otra parte, las capturas de pantalla realizadas con Spectacle, que versión a versión mejora a pasos agigantados, aparecen ahora en la lista de documentos recientes en el Panel de lugares. Este Panel de lugares es visible en Dolphin, los diálogos de archivos y en otras piezas de software como Gwenview.

Y una novedad más que importante es que ahora Dolphin dispone ahora de soporte táctil completo, con lo que ahora es más fácil usar Dolphin en pantallas táctiles como en convertibles (debo decir que en los Yoga de Lenovo funciona muy bien)

Como vemos, muchas mejoras interesantes que siguen manteniendo a Dolphin como el mejor explorador de archivos que puedes tener un tu dispositivo.

Más información: KDE

The GNOME project turned 23 this year, and despite equally persistent rumors to the contrary, it's still alive and kicking.

Just how alive, though? All I know is this: Where the topic of GNOME's health goes, accurate data rarely follows. Of course, there is data — lots of it in fact, in public source code repositories. Though flawed in many ways, it allows us to make comparisons to the past — and maybe predictions for the future: Are a few organizations carrying most of the workload, making them critical points of failure? Are new contributors able to pick up the slack from those who leave? Is the project graying (i.e. increasingly dominated by veterans)?

In one of my occasional fits of hubris, I set out to process this data to see if I could shake out anything meaningful. I'm usually fine with just satisfying my own curiosity and leaving it at that, but it's one of those times where the results seem interesting enough for a blog post. So here we are.

I'm going to lead with the nice graphs and follow on with a section on methodology. The latter is long, boring, and mandatory reading.

Active contributors

By generation

The stacked histogram above shows the number of contributors who touched the project on a yearly basis. Each contributor is assigned to a generational cohort based on the year of their first contribution. The cohorts tend to shrink over time as people leave.

There's a special "drive-by" cohort (in a fetching shade of off-white) for contributors who were only briefly involved, meaning all their activity fits in a three-month window. It's a big group. In a typical year, it numbers 200-400 persons who were not seen before or since. Most of them contribute a single commit.

According to this, GNOME peaked at slightly above 1,400 contributors in 2010 and went into decline with the GNOME 3.0 release the following year. However, 2020 saw the most contributors in a long time, even with preliminary data — there's still two weeks to go. Who knows if it's an anomaly or not. It's been an atypical year across the board.

This is the same histogram, but with per-month bins. There's a clear periodicity caused by the semiannual release cycle. The peak month was March 2011, right before the GNOME 3.0 release. About 450 contributors got involved that month.

The drive-by cohort is relatively smaller on a monthly basis. This makes sense, as it has little overlap from month to month, and the per-year bins tend to add them all up.

By affiliation

Above, the top 15 affiliations of active contributors. I've excluded personal accounts. This is pretty flawed (details below), but interesting nonetheless. For what it's worth, it mostly lines up with my memory of things.

The pattern tracks well with the total despite only capturing a minority portion of it. I think this means that paid and unpaid contributions are driven by the same underlying trends, or that there's a lot of the former hiding in the latter.

Commit count

By generation

Here I'm counting the number of commits per year in the various cohorts.

At first glance, this looks much less dire. However, note how newcomers are having a smaller impact, especially from 2014 on. And the 2018-2020 bounce is entirely due to a handful of veterans making a comeback.

Half the commits in 2020 were made by contributors who've been with the project for ten years or more. Also noteworthy, drive-by commits are a vanishingly small portion of the total.

By affiliation

Top 15 affiliations again, but now ordered by commit counts. It's safe to say that GNOME is dependent on paid developers in a big way. Specifically, and to no one's surprise, it leans heavily on Red Hat.

General observations

A few observations can be made with confidence:

• By F/OSS standards, the project is not unhealthy. It has hundreds of experienced and first-time contributors every year. It is well-organized and arguably well-funded compared to its peers. But:
• Every metric has the project peaking around 2010.
• A diminishing number of veterans is doing an increasing share of the work.
• Although recruitment is stable, newcomers don't seem to be hitting their stride in terms of commits.
• Corporate sponsorship is probably necessary to keep the project going, but the field of sponsors has kept thinning.

I think GNOME is addressing the risk factors competently by modernizing infrastructure (GitLab, Discourse). This has obvious value even in the absence of quantifiable results, but it'll be interesting to see if the effect can be measured over the next couple of years.

Diminished enthusiasm may also be due to there being fewer ways for a new contributor to make their mark or assume a role of responsibility. GNOME has become more conservative, certainly much more so than it was a decade ago in the run-up to GNOME 3. The rationale and phrasing in the announcement of the new versioning scheme (e.g. "Radical technological and design changes are too disruptive for maintainers, users, and developers") seems indicative of this trend¹.

Notes on methodology

So what's wrong with this analysis? If you're so inclined, you can find the details under the next couple of subheadings and pass harsh, harsh judgement.

I've set the unscientific rigor bar high enough to hopefully yield something useful, but low enough that I could do it in my spare time and not get stuck in the dreaded state commonly known as "90% done".

Module selection

I aggregated data from 189 Git repositories. The vast majority of these are hosted on gnome.org, with a handful from freedesktop.org and github.com. Commits are uniquely identified by their commit hash, meaning trivial duplicates are counted only once.

GNOME has always been a decentralized, big-tent project, so it's not obvious how to delineate it. I've tried to be fair by including most of the repositories from a full meta-gnome-desktop jhbuild, including fairly low-level dependencies like Cairo, Pango, and Pipewire, as well as past, present and would-be flagship applications under the GNOME umbrella. Documentation and infrastructure is represented, as are many archived projects (e.g. ORBit2, Bonobo, Sabayon, GAL).

I was a little uncertain about what to do with X.Org and Wayland. In the end I decided to include the latter, but not the former, since Wayland has close ties to GNOME (it even references GTK+ in its TODO file), while X.Org has its roots in the much older XFree86.

Mono is another project I resisted including; its development was tangential to GNOME proper, diverging completely in the most recent decade. However, I did include GtkSharp and several GNOME-hosted C# applications common on desktops in the 2005-2010 time frame.

Since I haven't established hard criteria for module selection, it's subject to various biases. Older code is probably underrepresented, since providers of important functionality were more loosely attached to the project early on (e.g. GNOME Online Accounts and Telepathy got pulled in, should I have included Gaim or Pidgin too? How about XChat?).

Anyway, the list isn't terrible, but there's room for improvement.

Contributor identities

Similar studies often identify contributors by their e-mail addresses. I used full author names instead, since there's good reason to think they're more stable over a 20-year time span. We're fairly consistent in spelling our own names, and we change them rarely (often never). On the other hand, e-mail addresses come and go with different hosting arrangements, employers, etc.

An added challenge with this approach is that sometimes different people have the exact same name. In practice, I'm not aware of any instances of this happening in GNOME. It seems to be rare enough that I doubt it'd introduce significant error in most projects.

I should add here that the drive-by cohort depends on a fair amount of hindsight (you never know when someone might come back with more contributions, but the likelihood drops off quickly as time passes). This means the cohorts for 2020 are preliminary. They'll be a lot more accurate with another run late next year.

Domain names

I'm using e-mail domain names as a proxy for organizations in some of the graphs. This is a notoriously unreliable approach for at least three reasons:

1. Contributors often use personal e-mail addresses for paid work, leading to significant undercounting in general.
2. Specific companies may require their employees (or ask them nicely) to use company e-mail for collaboration. Out of the listed companies, I know of at least one that definitely did this. However, there are many that don't, and these will be comparatively less well represented.
3. The mapping between DNS and organizations isn't one-to-one. A company may operate under multiple names or TLDs (e.g. .co.uk and .com).

Despite these weaknesses, it's common to slice the data this way. It's difficult to do better without access to semi-closed data troves, and depending on your views on privacy and ability to handle PII safely, it might not be something you'd want to get into anyway. But I bet you'd be well-positioned for it if you were, say, the corporate owner of both LinkedIn and GitHub.

When grouping by organization, the goal is to get an idea of which outside entities are sponsoring contributions. Therefore, I've filtered out addresses from the biggest mass e-mail providers like @gmail.com and project-centric providers of personal accounts (e.g. @gnome.org, @gtk.org).

I took the liberty of reassigning the personal domains of a few extra prolific authors who would've otherwise showed up as individual organizations. Since there's no way I'm doing it for everyone, this introduces some bias. The full details are in the project's metadata file (see: code).

Version control systems

Changeovers in version control systems divide GNOME's VCS history into three eras with noticeable discontinuities between them.

Before 1998: Dark ages

In the Bad Old Days, Free Software would often use plain RCS or no version control at all. I have basically no data for this era: The GIMP, being the ur-project from which GTK+ spawned, was imported to CVS in November 1997, but by then it had already been in development since at least mid-1995. It may be possible to reconstruct it somewhat by diffing old tarball releases. Linux historians have done this for the kernel.

1998-2009: Centralized

GNOME projects were mostly maintained in CVS from 1998 on, with infrastructure provided by Red Hat. A few companies (e.g. Ximian) maintained projects in their own CVS instances that were later consolidated under GNOME.

CVS had many limitations. For instance, history edits and other complex operations — like, oh, renaming a file — fell under the technical term "surgery" and the auspices of a competent server-side surgeon. The centralization of accounts also fostered a workflow where outside contributions were committed without any formal authorship metadata. This shows up in my plots as undercounting of active contributors.

GNOME moved to Subversion in 2007. While technically superior to CVS, it was still a centralized file-tracking solution and didn't change the workflow very much.

2009-present: Decentralized

Subversion didn't last long; 2009 saw the move to Git. The active contributor count shot up that year, and part of this is due to more accurate authorship metadata. I think there's a case to be made that involvement had been gradually increasing even before Git's introduction, but moving to a proper DVCS certainly didn't hurt.

Since a lot of contributors moved off @gnome.org in this switch, and affiliations are assigned based on e-mail addresses, the discontinuity is most visible in these graphs.

I expected the improved history management (and reduced commit anxiety) in Git's wake would also have produced more numerous commits. The data doesn't really bear this out — the count did increase the following year, but it's hard to distinguish from the general momentum leading up to GNOME 3.

Code

I wrote a small program to automate this somewhat. It's nothing much, but at least it can serve as a humorous example of what can happen when your reach starts to exceed awk's grasp and it occurs to you that hey, I should use Rust for scripting!

CSV files

I've uploaded the report data used in the charts in CSV format. It should be fairly self-explanatory and can be imported directly in LibreOffice (UTF-8, comma-separated).

Disclaimer

According to a quick tally, I've done enough work on GNOME projects for a place in the top 3% of committers². That's decent enough, but the lion's share of it is, shall we say, not very recent. I don't presume to speak for the project or, in fact, any group at all.

---

¹ Not necessarily a bad thing. There's something to be said for not constantly yanking the rug out from beneath everyone's feet.

² Humblebrag aside, I'd like to emphasize that since there are so many small contributions ("long tail"), it's easy to end up in a high percentile even with a modest commitment.