A few weeks ago I was invited to talk about firmware updates for servers using fwupd/LVFS at Prem’Day 2025. I gave the hardware vendors a really hard time, and got lots of instant feedback from customers in the the audience from the “little green thumbs” that people could raise. The main takeaway from the Prem’Day community seemed to be that proprietary tooling adds complexity without value, and using open ecosystems enable users to better operate their infrastructure. Since getting back to the UK I’ve had some really interesting discussions with various companies; there might be some nice announcements soon.

Welcome! In classic new-blog tradition, I felt it was a good idea to explain the title given to this little corner of blogs.gnome.org — and provide fair warning as to what sort of thoughts I’ll post here. GNOME is the Computer I’ve spent a lot of time lately answering the question “what is GNOME?” This question usually comes from my friends outside the tech industry. They work on film sets and fishing boats. They work in law firms, book stores, and hospitals. I don’t usually have a whiteboard handy to explain what GNOME is, so I’ve found myself approaching the question like this: Me: Have you heard of “Linux”? Them: Yes. Me: Okay, so. When you open your laptop and the thing you see is Windows? And when you unlock your phone and the thing you see is iOS? When you use a Linux computer, the thing you see is GNOME. I’m committing multiple sins with this oversimplification but if any of my friends are willing to let me elaborate, I do. That rarely happens. To these folks, and to me, GNOME is the computer. It’s the human part. The UI. The UX. The part you touch. An Environment for Everyone For those few friends who do permit me to elaborate, I’ll spend a moment explaining free desktops. But if they’re willing to put up with me, I’ll turn the conversation back to GNOME. After spending over two decades in the software industry, I’ve developed a deep appreciation for simple, opinionated, well-designed software. After a bicycle crash and three botched surgeries in 2014, I’ve also developed a deep appreciation for accessible software. The word “accessibility” contains a lot of nuance. Our industry tends to associate that word with an icon of a little human, arms outstretched. Of course it’s important for software to reach folks like me, who need to use computers in specific ways. But “accessibility” goes much farther than that. The root of accessibility is access: Does the computer speak your language? Does the computer understand your culture? Can you afford it? Can you share it? Can you fix it yourself? Is it really yours? Unlike most desktop software these days, GNOME can answer “yes” to all these questions. GNOME is Infrastructure Not only does accessible computing for everyone already exist, it is everywhere. I’ve seen GNOME in schools, wood shops, trading firms, government offices, universities, and every software company in my 20-year career. Infrastructure — whether libraries, parks, roads, or sewers — is a drab topic compared to “computing for everyone”. But it is no less important. Really, it is the other side of that coin and I’ll have a lot more to say on this topic. This blog will live at the intersection of these three topics: GNOME’s identity, mission, and reach.

April was light. exempi Released Exempi 2.6.6 to fix security issues from upstream. libopenraw Some minor fixes in the thumbnail extraction, with JXL support and locate larger Panasonic previews. Extract the exposure bias for Fuijfilm files. Added the latest Canon cameras (still the support of CR3 is work in progress). Released alpha.10 on May 1st.

This blog post talked about the "self written C++ standard library" I wrote for the fun of it (code here).The post got linked by Hackernews and Reddit. As is usual the majority of comments did not talk about the actual content but instead were focused on two tangential things. The first one being "this is not a full implementation of the C++ standard library as specified by the ISO standard, therefore the author is an idiot". I am, in actual fact, an idiot, but not due to project scope but because I assumed people on the Internet to have elementary reading comprehension skills. To make things clear: no, this is not an implementation of the ISO standard library. At no point was such a thing claimed. There is little point in writing one of those, there are several high quality implementations available. "Standard library" in this context means "a collection of low level functions and types that would be needed by most applications".The second discussion was around the fact that calling the C++ standard library "STL" was both wrong and proof that the person saying that does not understand the C++ language. This was followed by several "I am a C++ standard library implementer and everyone I know calls it the STL". Things deteriorated from there.The complexity questionExisting container implementations are complex by necessity. They need to handle things like types that can not be noexcept moved or copied. The amount of rollback code needed explodes very quickly and needs to be processed every time the header is included (because of templates). A reasonable point against writing your own containers is that eventually you need to support all the same complexity as existing ones because people will insert "bad" types into your container and complain when things fail. Thus you need to have all the same nasty, complex and brittle code as an STL implementation, only lacking decades of hardening to shake out all the bugs.That is true, but the beauty of having zero existing users is that you can do this:This is basically a concept that requires the type given to be noexcept-movable (and some other things that could arguably be removed). Now, instead of allowing any type under the sun, all containers require all types they get instantiated with to be WellBehaved. This means that the library does not have to care at all about types behaving badly because trying to use those results in a compiler error. A massive amount of complexity is thus eliminated in a single stroke.There are of course cases when you need to deal with types that are not well behaved. If you can tolerate a memory allocation per object, the simple solution is to use unique_ptr. OTOH if you have types that can't be reliably moved and which are so performance critical that you can't afford memory allocations, then you are probably going to write your own container code anyway. If you are in the position that you have badly behaved types that you can't update, can't tolerate an allocation and can't write your own containers, then that is your problem.Iterating things the native wayOne of the most common things I do with strings in Python is to split them on whitespace. In Python this is simple as there is only one string type, but in native code things are more complicated. What should the return type of mystring.split() be?vectorvectorA coroutine handleThe method should be a full template so you can customize it to output any custom string type (as every C++ code base has at least three of them)Something ranges something somethingThere is probably not a single correct answer. All of the options have different tradeoffs. Thus I implemented this in two ways. The first returns a vector as you would get in Python. The second one was a fully general, lazy and allocation-free method that uses the most unloved of language features: the void pointer.So given that you have a callback function like this:the split function becomes:This is as fully general as you can get without needing to muck about with templates, coroutines or monads (I don't actually know what monads are, I'm just counting on the fact that mentioning them makes you look cool). The cost is that the end user needs to write a small adapter lambda to use it.Iterating things the Python wayThe Python iteration protocol is surprisingly simple. The object being iterated needs to provide a .next() method that either returns the next value or throws a StopIteration exception. Obviously exceptions can't be used in native code because they are too slow, but the same effect can be achieved by returning an optional instead. Here's a unit test for an implementation of Python's range function.Sadly there is not a simple way to integrate this to native loop constructs without macros and even then it is a bit ugly.Current statusThe repo has basic functionality for strings (regular and enforced UTF-8), regexes and basic containers.Building the entire project has 8 individual compilation and linking steps and takes 0.8 seconds when using a single core on this laptop computer. Thus compiling a single source file with optimizations enabled takes ~ 0.1 seconds. Which is nice.The only cheat is that pystd uses ctre for regexes and it is precompiled.

Couple of solar-panel chaps showed up to estimate. Catch-up with Dave, Partner, mail chew & isolated my new pet bug. Wrote a unit test. Interested to see a newish phenomenon of users trying vibe coding in bug reports. Many programming problems should not be too hard for someone reasonable awake with little experience and some AI support to help learn; as long as that doens't consume lots of reviewer time I guess.

Some links for technical articles on various topics I read. The Defer Technical Specification: It Is Time - Explains the proposal for the next C language standard for defer. A guide to implement ActivityPub in a static site (or any website) - A guide to implement ActivityPub in a static website. 20 years of git - An history of git and its early days. Celebrating Git's 20th anniversary with creator Linus Torvalds - An interview with Linus Torvalds on the 20 years of git. I use Zip Bombs to Protect my Server - A technique of serving compressed zeros that a lot of bots don't handle properly. 6 usability improvements in GCC 15 - New in a GCC 15 near you, better error messages.

Tech planning call, plugged away at admin and testing 25.04. Spent some time reproducing and interesting problem and cutting a document down that shows that. 1:1 with Lily, then Naomi. More bug chasing. Home group in the evening.

Pleased to see 25.04 looking good, my blockers fixed at least. Fixed slide threading issue. Published the next TORF strip: "My friends see me as something of a visionary" Glad to see CODE 25.04 released - a great foundation for our next year of development. Based of course on the latest stable LibreOffice 25.02. Lots of encouraging new fixes, features and interactivity wins there: great work team & community - many thanks to all who have contributed.

The first *.py file in the gedit repository was added in 2005, 20 years ago. Since then, it seems that it has always been possible to write gedit plugins in Python. Well, this is no more. It deserves some explanation. Reducing the number of programming languages to deal with A multi-language project is much harder to manage. Now gedit only uses C and a little of Objective-C for the macOS support. The libgedit-* are entirely written in C. There was a Vala plugin (Find in Files) but has been removed in 2022 (unfortunately there is no replacement). The commit message already mentions the difficulty of working with multiple languages. So the problem is not new. Other reasons Making it easier to package gedit on Windows, avoiding the need to bundle a whole Python interpreter with the app. This also makes the package smaller and the app launches more quickly (better performances). There are also some inherent difficulties to maintain large Python codebases in the long run. gedit plugins are not specifically large, but still, the difficulties were present. (If Python is your thing, you may have a different experience and opinion. That's fine, there needs to be something for everybody). So over the recent years a few plugins have been rewritten from Python to C already. With the final goal of phasing out the Python support. This was a slow process, until ... Some PyGObject and GIRepository updates later GNOME 48 released in March comes with an update that basically makes all Python plugins unusable in gedit. It's more related to the code dealing with the loading of plugins, not the plugins themselves. More precisely, the latest version of PyGObject made the Python 3 loader of libpeas1 unusable (libpeas provides the plugin engine for gedit and other apps). libpeas1 and gedit depend on GIRepository-2.0 while the latest version of PyGObject has upgraded to GIRepository-3.0. It is not possible to use both GIRepository-2.0 and 3.0 at the same time in the same process. (Link to the issue). It's like weeds growing. If you do nothing, weeds grow and regression bugs happen. Note that it doesn't mean that nothing is done in gedit, there is still development done. But the GTK and GNOME platform apparently moves faster. gedit is no longer developed and maintained by a team of 5-6 dedicated hackers. So the project is no longer able to lead the peloton, but the application is still there and remains useful for many people! We (or - mainly - I) don't have the human resources to keep up with everything and be ahead of all the things to do. Hence ... Reducing/changing the scope of gedit gedit has for many years been between two things. (1) A great and easy-to-learn tool for beginners. And (2) some powerful plugins are or were available, so the text editor is also suitable for more advanced users, also in a professional context. So the scope of gedit is a bit unclear. What is clear is that we want from gedit something more than just writing quick notes. So something more than a simple notepad. But not as powerful and complete as Visual Studio Code (for instance, but you can pick your favorite IDE here, or Vim, Emacs). What is also clear for the path forward is a desire to well support markup languages like HTML, Markdown, etc. To support them even better than now, by adding some useful features for such languages. So in the context of the plugins removal, it means that some of them will not be re-implemented in C (or Rust or whatever). The set of features available through plugins will thus change. At least for the official plugins that are shipped with the gedit and gedit-plugins packages. Did I mention Rust? Even though there is a desire to deal with less programming languages, ideally having a single-language project, there is Rust. Rust might be the exception. Maybe (without doing any promises), third-party plugins can choose Rust instead of C. That would make for a better experience. Then, maybe, a Rust third-party plugin will eventually find its course into gedit proper. The impact for users This commit is the place to go to have the list of plugins that were implemented in Python and have been removed. But for the moment the Flatpak of gedit is mostly unaffected, because it can use the previous version of PyGObject while using the latest GNOME runtime. gedit on the Microsoft Store is also unaffected. One day however, the updates of gedit and gedit-plugins will roll out. Versions >= 48.2 are already affected. The idea is to re-implement in C a few plugins so that the change is not too disruptive for Flatpak and Windows users. As a conclusion, let's see what the future of gedit has in stock! Be it attracting Rust developers, or being a tool of choice for certain uses, remaining humble at its task of being an easy-to-learn and general-purpose text editor. This article was written by Sébastien Wilmet, currently the main developer behind gedit.

As promised, I wanted to write a blog post about this application. Enter TeX is a TeX / LaTeX text editor previously named LaTeXila and then GNOME LaTeX. It is based on the same libraries as gedit. Renames LaTeXila was a fun name that I picked up when I was a student back in 2009. Then the project was renamed to GNOME LaTeX in 2017 but it was not a great choice because of the GNOME trademark. Now it is called Enter TeX. By having "TeX" in the name is more future-proof than "LaTeX", because there is also Plain TeX, ConTeXt and GNU Texinfo. Only LaTeX is currently well supported by Enter TeX, but the support for other variants would be a welcome addition. Note that the settings and configuration files are automatically migrated from LaTeXila or GNOME LaTeX to Enter TeX. There is another rename: the namespace for the C code has been changed from "Latexila" to "Gtex", to have a shorter and better name. Other news If you're curious, you can read the top of the NEWS file, it has all the details. If I look at the achievements file, there is also the port from Autotools to Meson that was done recently and is worth mentioning. Known issue for the icons Enter TeX unfortunately suffers from a combination of changes in adwaita-icon-theme and GThemedIcon (part of GIO). Link to the issue on GitLab. Compare the two screenshots and choose the one you prefer: As an interim solution, what I do is to install adwaita-icon-theme 41.0 in the same prefix as where Enter TeX is installed (not a system-wide prefix). To summarize LaTeXila -> GNOME LaTeX -> Enter TeX C code namespace: Latexila -> Gtex Build system: Autotools -> Meson An old version of adwaita-icon-theme is necessary. This article was written by Sébastien Wilmet, currently the main developer behind Enter TeX.

Long planning call; sync with Karen, lunch, catch up with Kendy, sync with Eloy, admin. Out for a run with J. multi-partner call, mail.

WebKitGTK has a bunch of different confusing API versions. Here are the three API versions that are currently supported by upstream: webkitgtk-6.0: This is WebKitGTK for GTK 4 (and libsoup 3), introduced in WebKitGTK 2.40. This is what’s built by default if you build WebKit with -DPORT=GTK. webkit2gtk-4.1: This is WebKitGTK for GTK 3 and libsoup 3, introduced in WebKitGTK 2.32. Get this by building with -DPORT=GTK -DUSE_GTK3=ON. webkit2gtk-4.0: This is WebKitGTK for GTK 3 and libsoup 2, introduced in WebKitGTK 2.6. Get this by building with -DPORT=GTK -DUSE_GTK3=ON -DUSE_SOUP2=ON. webkitgtk-6.0 contains a bunch of API changes, and all deprecated APIs were removed. If you’re upgrading to webkitgtk-6.0, then you’re also upgrading your application from GTK 3 to GTK 4, and have to adapt to much bigger GTK API changes anyway, so this seemed like a good opportunity to break compatibility and fix old mistakes for the first time in a very long time. webkit2gtk-4.1 is exactly the same as webkit2gtk-4.0, except for the libsoup API version that it links against. webkit2gtk-4.0 is — remarkably — mostly API stable since it was released in September 2014. Some particular C APIs have been deprecated and don’t work properly anymore, but no stable C APIs have been removed during this time, and library ABI is maintained. (Caveat: WebKitGTK used to have unstable DOM APIs, some of which were removed before the DOM API was eventually stabilized. Nowadays, the DOM APIs are all stable but deprecated in webkit2gtk-4.1 and webkit2gtk-4.0, and removed in webkitgtk-6.0.) If you are interested in history, here are the older API versions that do not matter anymore: webkit2gtk-5.0: This was an unstable API version used during development of the GTK 4 API, intended for WebKit developers rather than application developers. It was obsoleted by webkitgtk-6.0 in WebKitGTK 2.40. webkit2gtk-3.0: original API version of WebKitGTK for GTK 3 and libsoup 2, obsoleted by webkit2gtk-4.0. This was the original “WebKit 2” API version, which was only used by a few applications before it was removed one decade ago (history). webkitgtk-3.0: note the missing “2”, this is “WebKit 1” (predating the modern multiprocess architecture) for GTK 3. This API version was widely-used on Linux, and its removal one decade ago precipitated a security crisis which I called The Great API Break. (This crisis was worth it. Modern WebKit’s multiprocess architecture is far more secure than the old single-process architecture.) webkitgtk-1.0: the original WebKitGTK API version, this is “WebKit 1” for GTK 2. This API version was also widely-used on Linux before it was removed in The Great API Break. Fedora and RHEL users, are you confused by all the different confusing downstream package names? Here is your map: webkitgtk6.0, webkit2gtk4.1, and webkit2gtk4.0: This is the current binary package naming in Fedora, corresponding precisely to the WebKitGTK API version to reduce confusion. webkit2gtk3: old name for webkit2gtk4.0, still used in RHEL 9 and RHEL 8 webkitgtk4: even older name for webkit2gtk4.0, still used in RHEL 7 webkitgtk3: this is the webkit2gtk-3.0 API version, still used in RHEL 7 webkitgtk: this is webkitgtk-1.0, used in RHEL 6 Notably, webkit2gtk4.0, webkit2gtk3, and webkitgtk4 are all the same thing.

Introduction: GNOME GitLab now uses macOS runners from MacStadium for managing our macOS CI pipeline. This offers significant improvements in supporting the GNOME platform on macOS. In this blog, we’ll cover the event timeline of macOS CI in GNOME GitLab and the technical details of the new infrastructure setup from MacStadium. Background: Around mid 2023, the GNOME Infrastructure Team decided to retire the existing macOS CI runners for a handful of reasons as explained in this post by Emmanuele Bassi. They were x86_64 runners which were quite outdated technically, as they were replaced by better and faster Apple Silicon M series ARM SoCs (specifically Apple M1) from Nov 2020. There was no macOS CI in GNOME GitLab since then. GNOME core projects like GTK, GLib and few apps still provided macOS support on a best effort basis: meaning development and testing would be done on user machines. Though this is far from perfect, this provided some basic macOS support for GNOME projects. Infrastructure help from René: René de Hesselle is a member of Inkscape’s Project Leadership Committee and an open source developer who specializes in building, packaging and porting applications to the macOS platform. Looking into the macOS CI issues GNOME projects were facing, René offered to help with the macOS effort in GNOME, which was greatly appreciated by GNOME developers. René has been assisting core libraries like GLib, GTK and GNOME apps to build in macOS. To address the macOS CI limitation, René went a step further and provided a self hosted GitLab macOS CI runner. With assistance from the GNOME Infrastructure Team, the self hosted runner was made available to projects across GNOME. This proved to be really useful, as it increased the pace of development in macOS. Scalability and Sustainability Issues: Over time, as more projects switched to using the self hosted macOS CI runner, it was becoming evident that this solution would not be effective for the scale of GNOME and not sustainable in the long term. René opened this topic for discussion in this post. It was quite evident that we needed an enterprise solution to offer scalable and sustainable macOS CI service. This is when MacStadium’s FOSS program was highlighted as a possible solution in GNOME Discourse. MacStadium, FOSS and GNOME: MacStadium is well known in the open source world for sponsoring developers of open source projects for the Apple platform, including macOS, iOS, tvOS, and watchOS. The GNOME Team got in touch with MacStadium for sponsoring macOS CI runners under their FOSS program. Though the MacStadium FOSS program was not available as it was already at capacity, MacStadium was excited in partnering with GNOME. Special thanks to Lauren Cabana (Director, Marketing) from MacStadium for actively pursuing this effort and making this collaboration possible. MacStadium Orka Cluster solution: As part of this collaboration, MacStadium has offered the following infrastructure setup based on our requirements: Orka (Orchestration with Kubernetes on Apple) Cluster. Dedicated network with firewall and VPN. 1 TB NAS storage. 2 x Mac mini (M1, 8-core CPU, 10-core GPU, 16GB RAM, 1TB SSD). This is a significant bump in hardware specs compared to the current solution, allowing us to run more builds simultaneously. But the biggest benefit is having access to a turnkey solution that provides ephemeral machines: build isolation is no longer a concern and restrictions on customizability can be lifted, making it possible to open macOS CI instance-wide on GNOME GitLab with minimal administrative oversight. This setup is located in MacStadium’s Dublin data center. Thanks to MacStadium for sponsoring this infrastructure upgrade! Thanks and Mentions: Richard Littauer – for interfacing with MacStadium via calls / emails and active participation. René de Hesselle – for actively taking part in all technical discussions. Philip Withnall – for coordinating efforts within GNOME. Bartłomiej Piotrowski – for setting up GNOME / MacStadium accounts.

I know that I will never convince everyone to use Builder for development. Even I have a hard time getting myself out of the terminal at times. Foundry comes in two forms, an executable and a library. The executable is just a bunch of commands and libfoundry is meant for building your own IDE (like Builder) or specialized tooling. # initialize .foundry directory if never done before cd my-project/ foundry init If you go into most GNOME applications, they likely have a Flatpak manifest. Builder uses this to auto-discover a lot about a project. Foundry is no different. # Build the project, just like Builder would do foundry build You can run this from any directory in your project as it will scan upwards to locate the .foundry/ directory that contains project state. It will also do incremental building just like Builder does. # Run the project, just like Builder would do foundry run # Run a specific command in place of the default program. # Useful to test something with "runtime" instead of # build environment. foundry run -- gtk4-demo Running the project will setup the necessary incremental flatpak pipelines and auxiliary tooling like an a11y bus, font integration, and what not. Your application will be run in the Flatpak build container based on the finish-args. This does require building the application to ensure the runtime environment is setup correctly. # Pull updated project dependencies. foundry dependencies update Updating your deps is pretty painless. This is not done automatically unless the dependency is missing so that we don’t have to constantly hammer remote servers on every build request. # Run a shell in the build pipeline, launches in builddir foundry devenv # Run a specific command in build pipeline foundry devenv -- ps aux You can get a terminal shell in the build pipeline (much like ctrl+alt+shift+t in Builder. # Lots of commands to inspect the build pipeline foundry pipeline info # Alias to foundry build foundry pipeline build # Invalidate all pipeline stages foundry pipeline invalidate # Purge (remove build files/artifacts/etc) to force # a clean build foundry pipeline purge # clean, configure, export, rebuild, which, install # all provide additional pipeline operations You can interact with the active build pipeline using the above commands. Sometimes you might want to know what compiler flags will get used with tooling on a specific file. That is made available via the pipeline as well. foundry pipeline flags path/to/file.c Maybe you need a language server for integrating with another editor. That is pretty easy to do for the supported languages by using the lsp command. $ foundry lsp list Name Languages zls 'zig' vhdl-language-server 'vhdl' vala-language-server 'vala' 'genie' ts-language-server 'js' 'jsx' 'typescript' 'typescript-jsx' sourcekit-lsp 'swift' serve-d 'd' rust-analyzer 'rust' ruff 'python3' 'python' pylsp 'python3' 'python' mesonlsp 'meson' lua-language-server 'lua' jedi-language-server 'python' jdtls 'java' intelephense 'php' gopls 'go' glsl-language-server 'glsl' elixir-ls 'elixir' clangd 'c' 'cpp' 'chdr' 'cpphdr' 'objc' blueprint 'blueprint' bash-language-server 'sh' # use stdin/stdout to communicate with an LSP for python3 $ foundry lsp run python3 If you have multiple project configurations, you can look through them and select the active one. Just switch configs and run, Foundry will do the rest. foundry config list ... foundry config switch flatpak:app.devsuite.Manuals.Devel.json foundry run Want to get a .flatpak you can copy to another system to test? foundry export ... Artifacts: file:///.../apps.devsuite.Manuals.Devel.flatpak You can switch devices in case you have deviced running somewhere like a phone or tablet. Then running should deploy to that system and run it there. foundry device list ... foundry device switch some_device foundry run You can get the URI to documentation which could allow you to integrate with other editors. Like many commands, you can use --format=json to get the output in an easy-to-parse format for editor plugins. # list available doc bundles to install foundry doc bundle list ... # install docs for GNOME 48 foundry doc bundle install flatpak/org.gnome.Sdk.Docs/48/user # Find GtkWidget documentation query doc query --format=json GtkWidget Many settings can be tweaked using foundry settings set .... Just tab-complete around to explore. Anyway, hopefully that serves as a quick intro into some of the things you can do with Foundry already as it progresses towards being a fully-fledged replacement for Builder’s internals.

I finally got around this past week to getting Manuals ported to libfoundry. That was something I wanted to do early so that I can rapidly get away from 3 versions of the documentation engine and Flatpak SDK management code. Currently it existed in Manuals, Builder, and Foundry, and soon we’ll get it to just Foundry. That also makes Manuals the first application to use libfoundry which resulted in lots of tree-shaking and things are looking bright! I very much look forward to getting Builder rebased on libfoundry. While I was at it, I ticked off a number of requested design issues as part of the Incubator submission. This afternoon it also got support for narrow views meaning you can run it on a GNOME-enabled phone. Probably not how most people will use it, but hey, maybe you have actually good public transportation where you are and some free time.

This post is a response to what Tobias posted yesterday on his blog. I would really prefer not be writing it. There are many other things that I would prefer to be doing, and I do not enjoy engaging in public disagreements. I honestly find all of this very stressful and unpleasant, but here we are. For context, I joined the board in July last year, having previously been on the board from 2015 to 2021. This means that I wasn’t on the board during some of the events and decisions described in Tobias’s post. I am assuming that I am not one of the unnamed individuals he is calling on to resign, though I would be significantly impacted if that were to happen. The post here is a personal view, based on my close involvement with the issues described in Tobias’s post. As such, it is not an official board position, and other directors may disagree with me on some points. It’s possible that the board may produce its own official statement in the future, but boards are inherently slow-moving beasts, and I wanted to get something posted sooner rather than later. I want to start by saying that it is difficult to respond to Tobias’s post. The Foundation has a policy that we don’t comment on specific code of conduct cases, in order to protect the privacy of those involved. And, when you get down to it, this is mostly about the particulars of one specific case. Without being able to discuss those particulars, it is hard to say very much at all. That, in my opinion, is the elephant in the room. The other reason that it is difficult to respond is there are just so many broad brush accusations in the blog post. It presents power conflicts and financial mismanagement and reckless behaviour and so on and so forth. It’s impossible to address every point. Instead, what I will do is provide a fairly high-level view of each of the two main themes in the post, while calling out what I consider to be the main inaccuracies. The first of those themes is the code of conduct decision, and the second relates to the performance of the Foundation. The big elephant In the blog post, Tobias throws around a lot of accusations and suggestions about the code of conduct decision to suspend Sonny Piers from the GNOME project. His description of the chain of events is both misleading and a misrepresentation of what happened. Then there’s an accusation of recklessness, as well as an accusation that the code of conduct decision was somehow politically motivated. All of this is clearly intended to question and undermine the code of conduct decision, and to present a picture of mismanagement at the foundation. My view is that, despite the various twists and turns involved in the decision making process for this case, and all the questions and complexities involved, it basically boils down to one simple question: was the decision to suspend Sonny the correct one? My view, as someone who has spent a significant amount of time looking at the evidence, talking to the people involved, and considering it from different perspectives, is that it was. And this is not just my personal view. The board has looked at this issue over and over, and we have had other parties come in to look at it, and we have always come to the conclusion that some kind of suspension was appropriate. Our code of conduct committee came to this conclusion. Multiple boards came to this conclusion. At least one third party who looked at the case came to this conclusion. I understand why people have concerns and questions about the decision. I’m sympathetic to the experiences of those individuals, and I understand why they have doubts. I understand that some of them have been badly affected. However, ultimately, the board needs to stand up for the code of conduct. The code of conduct is what provides safety for our community. We do not get to set it aside when it becomes inconvenient. The argument that the code of conduct decision was somehow politically motivated is false. We even had an external reviewer come in and look at the case, who confirmed this. Their report was provided to Tobias already. He continues to make this accusation despite it standing in opposition to the information that we have provided him with. Tobias seems to think that Sonny’s importance to the GNOME project should have been taken into account in our decision for the code of conduct case. To me, this would imply that project leaders would operate according to a different, less stringent, set of conduct rules from other contributors. I believe that this would be wrong. The code of conduct has to apply to everyone equally. We need to protect our community from leaders just as much as we need to protect them from anyone else. No one is suggesting that the management of the code of conduct decision was good. Communication and management should have been better. Community members were significantly impacted. We have sincerely apologised to those involved, and are more than willing to admit our failings. We’ve also been working to ensure that these problems don’t happen again, and that’s something that I personally continue to spend time and energy on. However, to understand those failings, you also have to look back at the situation we faced last year: we had just lost an ED, board members were burned out, and our processes were being tested in a way that they never had been before. We still had all the usual board and foundation work that needed taking care of. In the middle of it all, elections happened and the board membership changed. It was a complex, shifting, and demanding situation, which looks rather different in retrospect to how it was experienced at the time. We learned a lot of lessons, that’s for sure. The other elephant The other part of Tobias’s post addresses the performance of the Foundation. He points out various problems and challenges, some of which are real. Unfortunately, while being convenient, the theory that all of these challenges are the result of the incompetence of a few individuals is, like most convenient answers, incorrect. The reality is more complex. One of the major factors for the Foundation’s current situation is our recent history with Executive Directors. Neil left as ED in November 2022. It took us about a year to hire Holly, who was ED for seven months, during which time she had to take a non-trivial amount of time off. And the Foundation is a small organisation – there aren’t lots of people around to pick up the slack when someone leaves. Given these circumstances, it’s unsurprising that the Foundation’s plans have changed, or that they didn’t happen in the way we’d hoped. This is why the current board has been focusing on and expending considerable effort in recruiting a new executive director, who will be joining us very soon. Hurrah! Tobias’s proposition that anyone who tries to change the Foundation gets burned out or banned is not true. I am living proof of this. I have changed the Foundation in the past, and continue to change it as part of my role as director. The Foundation today is radically different from the one I first joined in 2015, and continues to evolve and change. A lot of this is due to the interventions of previous and current directors over time. Amid all this, it’s also important not to forget all the things that the Foundation has been successfully doing in recent years! I went into some of this in my recent blog post, which provides more details than I can here. It is worth stressing that the ongoing successes of the Foundation are mostly thanks to the dedication of its staff. We’ve run successful conferences. We’ve supported Flathub during which time it has experienced extraordinary growth. We’ve supported development programs. And the organisation has kept running, sailing through our taxes and registrations and all those other bureaucratic requirements. On resignations From the outside the GNOME Foundation can seem a little opaque. Part of the reason for that is that, as a board, we have to deal with sensitive and confidential matters, so much of the work we do happens behind closed doors. However, when you are on the board you quickly learn that it is really much like any other community-based open source team: there’s usually more work to do than we have capacity for, and the majority of the work gets done by a small minority of contributors. Speaking as part of that minority, I don’t think that it would be beneficial for members of the board to resign. It would just mean fewer people being available to do the work, and we are already stretched for resources. I’m also of the view that no one should be asked to resign in response to upholding the code of conduct. Conduct work is difficult and important. It requires tough decisions. As a community we need to support the people doing it. And if people think we should have different directors, well, that’s what the elections are for. Closing Readers might wonder why the Foundation has not spoken publicly about this topic before. The main reasons were confidentiality and legal concerns. We have also tried very hard to respect the wishes of those who have been involved and affected. Now with Tobias’s post it is harder to avoid saying things in public. I’m personally skeptical of how useful this is: with opaque and complex issues like these, public discussions tend to generate more questions than they do answers. Contributor relationships are unfortunately likely going to get damaged. But again, here we are. It should be said that while the foundation hasn’t spoken publicly about these issues, we have expended significant effort engaging with community members behind the scenes. We’ve had meetings where we’ve explained as much of what has happened as we can. We even went so far as to commission an external report which we made available to those individuals. We continue to work on improving our processes in response to the, ahem, feedback we’ve received. I personally remain committed to this. I know that progress in some areas has been slow, but the work continues and is meaningful. Finally: I am sure that there are contributors who will disagree with what I’ve written here. If you are one of those people, I’m sorry that you feel that way. I still appreciate you, and I understand how difficult it is. It is difficult for all of us.

The desktop team in Red Hat has another open position. We’re looking for someone to work on Flatpak automation, for someone who enjoys working on infrastructure. Although the job description states 2+ years of experience, it’s suitable for juniors. Formal experience can be replaced by relevant open source contributions. Being onsite in Brno, Czech Republic is preferred, but not required. We’re open to hiring good candidates elsewhere, too. If you’d like to know more about the job before formally applying, don’t hesitate to contact me on Mastodon, Signal, Matrix (@eischmann at fedora.im), or email.

After more than an year after, Boatswain 5.0 is finally out. It took me a long time to push it to the finish line, but I’m relatively happy with how it turned out, and it brings some nice features. Let’s take a quick look at what’s new in this release! New Devices Boatswain 5.0 comes with support for 2 new device models from Elgado: Stream Deck Plus, and Stream Deck Neo. Support for Elgato Stream Deck Plus came after the massively successful fundraising campaign from last year. A huge thanks to everyone that contributed to it! As for Elgato Stream Deck Neo, I tentatively introduced support for it without actually having a device to test, so if there’s anyone out there that can test it, that’d be absolutely appreciated. Support for Stream Deck Plus was probably the main reason it took so long to release Boatswain 5.0. The entirety of the app was originally written under the assumption that all devices were simply a grid of buttons. Introducing a touchscreen, and dials that act as buttons, required basically rewriting most of the app. I used this opportunity to make Boatswain able to handle any kind of device, with any kind of layout. Everything is represented as regions in a grid layout. Simple Stream Deck devices just contain a button grid; Stream Deck Plus contains a button grid, a touchscreen, and a dial grid. Keyboard Shortcuts The new Keyboard Shortcut action allows executing any keyboard shortcut – or any keyboard event in general – on the desktop. This seems to work better than I could have anticipated! Under the hood, this action uses the Remote Desktop portal be able to inject input on the desktop. Locally controlling the desktop was probably not on the original goals of the portal, but alas, it fit the use case perfectly! Paired with folders, Keyboard Shortcuts are very powerful, especially for large and complex software with a large number of shortcuts. Next Steps This release might be a little disappointing as it took so long, and yet didn’t come as packed with new features. And yet, this was the largest release of Boatswain, perhaps larger than the initial release even. I’ve reached a point where I’m mostly satisfied with how the internals work now. So much so that, right after the Boatswain 5.0 release, I was able to split the core logic of the app into an internal library, and hide device-specific details from the rest of the app. This paved the way for adding a testing framework using umockdev, and also will allow adding support for devices from other brands such as Loupedeck. If you have any Stream Deck-like device and wish to see it supported in Boatswain, now’s your chance! For Boatswain 6, I personally want to focus on 2 major features: Make Boatswain use the new USB portal. One of my goals with Boatswain is to make it a reference app, using the most modern platform features available – and adding missing features if necessary. The USB portal is an obvious choice! Remove X11 support. This might come as a controversial decision, but I don’t personally use X11 anymore, do not support it, and will not work on fixing bugs that only exist there. As such, I think it’s fair to just remove X11 support from the apps that I maintain. Practically speaking, this just means removing --socket=fallback-x11, and users can add back this permission using Flatseal; but please do not expect any kind of support anymore. Some features that would be lovely to have, but we currently don’t have either because we lack platform support (i.e. portals), or simply because nobody sat down and wrote it: Tracking the current desktop state, such as the focused app, the session idle state, etc. This will be useful for contextual actions. Clipboard integration. In theory people can simulate this using the Keyboard Shortcuts action, but proper clipboard integration will work better and in more cases. Picking and launching apps from the host system. This needs to happen through portals which currently don’t exist. A fancy visual icon editor so that people can create their pretty icons in the app! If any UI designer is reading, please consider yourself assigned to this little project. Support for custom backgrounds in the touchscreen. I did not have time to finish it before the 5.0 release, but it shouldn’t be too hard to add it. A proper testing framework! Finally, I’d like to thank my Ko-Fi and YouTube supporters for all the patience and for enabling me to do this work. The fundraiser campaign last year was a massive success, and I’m happy to see the all this progress! You all are awesome and I truly appreciate the support. Keep an eye on this space as there may be more good news in the near future!

Over the last two years I’ve worked a bit in my spare time on the user documentation of GIMP, a Free & Open Source Image Editor.While I personally still consider it pretty bad user documentation regarding style inconsistency, duplication of topics, “organic growth”, and lack of task orientation, I managed to put some lipstick on that pig across nearly 900 commits.I was sometimes rather ruthless pushing my changes (plus I am only a simple contributor and not a GIMP developer) so I’d like to thank Jacob Boerema for their patience and lenience. In particular that led to pretty consistent and up-to-date user interface dialog screenshots using the default theme (a fun game in a repository with about 2000 images and no filename scheme whatsoever), less trivial screenshots; people know how menus look like and all their entries are covered by accompanying text anyway (which created more work for translators), all application icons updated to the default monochrome theme, in SVG format, located in one single directory within the docs repository, using the same filenames as in the GIMP code repository (so there’s theoretically a chance of maintenance), adding some icons to text because “click the fifth icon” isn’t particularly user-friendly (especially for RTL folks), slightly less quadruplication of string variants expressing the same meaning (which created more work for translators). An interesting remaining issue is whether to remove outdated ancient localized screenshots and where to draw the line. Does having localized strings in the screenshot (not everybody prefers English) outweigh an outdated user interface in the screenshot (wrong numbers of buttons, or dropdowns instead of radio buttons)? Your mileage may vary. Obviously there is much more to do, for example maybe rewriting everything from scratch or splitting screenshot files of translatable UI dialogs and non-translatable example images mashed into one single image file into two separate files because, again, translators and lower maintenance costs. If you enjoy dealing with Docbook and all its quirks, see the open GIMP help issues or even write merge requests.

If my phone is making me miserable my constantly nagging me for attention, surely the solution must be to ditch it and take a dumb phone that can only place calls and send texts? Except calls are particularly intrusive interruptions, and the only texts I receive are from couriers. My family and friends use iMessage or Signal. And what about the pictures I can snap in a few seconds by pulling my phone from my pocket? What about GPS navigation? What about those parking lots where you can only pay with an app? What if I need to order a cab in a country I don't speak the language of? What about using my phone app as a 2FA from the bank as the PSD2 practically requires? I thought about using a dumb down smartphone like the Lite Phone III or any of the other dumbed-down Android phones. In practice it doesn't work for me, because most of them either don't let me use the apps I need or let me break out of the dumb mode to use the app. At this point, why using a dumbed down smartphone at all? I don't need a dumb(ed down smart)phone. I need the convenience of my smartphone, but I need to use intentionally instead of being dragged to it. My phone was already in silent mode all the time because I can't stand being interrupted loudly by it unless it's an actual emergency. But whenever a notification pops on the screen it brightens up, drags my attention to it, and even if I don't want to interact with it it stays in the back of my head until I finally unlock the phone and have a look at what it's all about. What I was missing was a sense of priority for notifications. To stay focused on what I cared about, I needed my phone to hold back the unimportant notifications and tell me when something important happened. I could already deny some app the authorization to display notifications, but that's a double edged sword. If I do so with messaging apps I end up compulsively checking them to see if I missed anything important. What solved it for me was the Focus feature of the iPhone. Instead of using the Do Not Disturb mode, I've configured the Personal Focus profile. I configured it so No notifications at all appear on my screen. If my favorite contacts call me I will be notified. If someone calls me twice within three minutes it will bypass the protection. If an app has a Time Sensitive notification to send me, it will bypass the protection. All the rest is filtered out. As a result I have a phone that doesn't actively nag me for attention. Because it notifies me when something truly important happens, I don't have to check it regularly out of Fear Of Missing Out. This tweak is part of a broader effort to reclaim my attention capacity.

Up early, sync with Dave, Tracie & a partner. Encouraging monthly all-hands. Collabora quarterly mgmt meeting for much of the afternoon. Published the next strip: Draft Governance Rules

In a few weeks it’ll be one year since a board member of the GNOME Foundation was disappeared under very suspicious circumstances. Very little has been said or done about this in public since then. The intentions behind keeping everything internal were good — the hope was to get to a resolution without unnecessary conflict. However, because there’s no non-public way to have discussions across the entire community, and with this dragging on longer and longer, what I’ve seen is partial facts and misunderstandings spreading across different sub-groups, making it harder to talk to each other. I’m now convinced it’s better to break the silence and start having this conversations across the entire project, rather than letting the conflict continue to fester in the background. That’s not to say nothing has been happening. Over the past year, a number of people from the community (including myself), and some members of the board have tried to resolve this behind the scenes. On a personal level, I’d like to thank all the board members involved for their efforts, even if we didn’t always see eye to eye. Medium-term I’m hopeful that some positive policy changes can be made as a result of this process. One important thing to note is that nobody involved is against Codes of Conduct. The problem here is the Foundation’s structural dysfunction, bad leadership, and the way the CoC was used in this case as a result. I’m aware of the charged nature of the subject, and the potential for feeding right wing narratives, but I think it’s also important to not let that deter us from discussing these very real issues. But just to be extra clear: Fuck Nazis, GNOME is Antifa. Sonny has been out since last summer, and as far as I know he’s currently not interested in investing more energy into this. That’s understandable given how he’s been treated, but the rest of us are still here, and we still need to work together. For that we need, if not justice, at least closure, and a way forward. In this case someone was disappeared entirely from the community with no recourse, no attempts to de-escalate, no process for re-integration, and no communication to the rest of the project (not until months later anyway). Having talked to members of other projects’ CoC structures this is highly unusual, especially completely out of the blue against a well-integrated member of the project. While the details of this case are unknown to most of the community due to the (understandable) need to keep CoC reports confidential, what is known (semi-) publicly paints a pretty damning picture all by itself: A first-time CoC complaint was met with an immediate ban A week later the ban was suspended, and a mediation promised The 2024 board elections were held a few weeks later without informing the electorate about the ban 2 months later the ban was re-instated unilaterally, against the wishes of the new board There was an (unsuccessful) vote to remove the chairman of the CoC committee from the board and CoC committee Given the above, I think it’s fair to say that the people who were on the board and CoC committee when the ban happened, have, at the very least, acted with incredible recklessness. The haphazard and intransparent way in which they handled this case, the incoherence of their subsequent actions, and the lack of communication have have caused great damage to the project. Among other things, in Sonny Piers they have cost us one of our most prolific developers and organizers, and in the STF development team our most successful program in recent history. What perhaps not everyone’s aware of is that we were working on making this team permanent and tried to apply for followup funding from different sources. None of this materialized due to the ban and the events surrounding it, and the team has since been disbanded. In an alternate world where this had not happened we could be looking at a very different Foundation today, with an arm that strategically funds ongoing development and can employ community members. More importantly however, we’re now in a situation where large parts of the community do not trust our CoC structure because they feel it can be weaponized as part of internal power struggles. This ban was only the latest in a long series of failures, missteps, and broken promises by the Foundation. In addition to the recent financial problems and operational failures (e.g. not handling internships, repeatedly messing up invoicing, not responding to time-sensitive communication), all strategic initiatives over the past 5+ years have either stalled or just never happened (e.g. Flathub payments (2019), local-first (2021), development initiative (2024)). I think there are structural reasons at the root of many of these issues, but it’s also true that much of the Foundation leadership and staff has not changed throughout this period, and that new people joining the board and trying to improve things tend to get frustrated and give up quickly (or in Sonny’s case, get banned). This is a problem we need to confront. To those on the board and CoC committee who were involved in Sonny’s ban: I’m asking you to step down from your positions, and take some time off from Foundation politics. I know you know you fucked up, and I know you care about this project, like we all do. Whatever your reasons at the time, consider what’s best for the project now. Nobody can undo what happened, but in the medium-term I’m actually hopeful that reconciliation is possible and that both the Foundation and community can come out of this stronger than before. I don’t think that can happen under the current leadership though. To everyone else: My hope in talking openly about this is that we can get closer to a common understanding of the situation. It seems unlikely that we can resolve this quickly, but I’d at least like to make a start. Eventually I hope we can have some mediated sessions for people from across the community to process the many feelings about this, and see how we can heal these wounds. Perhaps we could organize something at GUADEC this summer — if anyone would be interested in that, let me know.

Planning call, sync with Karen, marketing content-call. Monthly management meeting, CEO call, tried to catch-up on mail.

Hello Matrix users, please review the following: Update from Matrix Trust & Safety team regarding attacks on the Matrix network GNOME’s new Matrix safety guidelines Be cautious with unexpected private message invites. Do not accept private message invites from users you do not recognize. If you want to talk to somebody who has rejected your invite, contact them in a public room first. Fractal users: Fractal 11.rc will block media preview by default in public rooms, and can be configured to additionally block media preview in private rooms if desired. Matrix server administrators: please review the Matrix.org Foundation announcement Introducing Policy Servers.