Andy Holmes

Opaque Governance

Andy Holmes — Sat, 03 May 2025 18:27:00 GMT

Recently, Tobias Bernard posted a retrospective of his (and our) experience engaging with the GNOME Foundation regarding the removal of Sonny Piers from our community, followed by a response from Allan Day. I know it's difficult and stressful to talk about; a lot of people just want it to go away. It took a long time to write this.

The details regarding the removal of Sonny Piers will never be publicized, but I respectfully disagree that all discussion of the community impact should happen internally. Regardless of the circumstances at the time, the GNOME Foundation made a decision to publicly remove Sonny Piers from the community and if we are asked to assume good faith, we should be able expect the same good faith when we criticize governance.

# Safety in the Community

The case of Sonny Piers includes GNOME Foundation membership, a seat on the board of directors and employment as a project coordinator. Circumstances these complex do not relate to the Code of Conduct Committee (CoCC) in its typical operation.

The Engagement Team also plays an active role in day-to-day moderation, as well as the community members from diverse backgrounds serving as moderators in the many project channels. Recently a member of the CoCC helped organize a communication channel and new guidelines for moderators, which has already improved coordination and response times across the various platforms.

The GNOME community is a safe place to engage in open source and the matters discussed here should not prevent you from reporting an incident or flagging content for moderation.

CoC Links

# Opaque Context

The following is a very incomplete timeline, providing some amount context for my personal perspective.

In July 2024, many of us in the community were shocked to hear that Sonny Piers had been removed as a GNOME Foundation director, stripped of his membership, had all accounts locked and a permanent ban put in place. More unsettling, he was named as the recipient of a Code of Conduct complaint, but obviously without any details regarding the incident.

With such limited information, for many there was little justification to protest the decision itself, except that the degree of disciplinary action implied behaviour extremely out of character for Sonny.

By October, three months had passed and lacking any meaningful resolution, enough concern had grown in parts of the community to have a conversation. It was decided to compose a letter directly to the Board and, after lengthy discussion of the content, those that agreed signed and it was received generally well by the Board.

The resulting meetings were draining for everyone involved, often with visible exertion of good faith from those present. The many constructive results include several amendments to CoCC procedures, more comprehensive and equitable agreements for contractors, and a fair amount of clarification regarding the constraints the Board was under at the time.

By December, I had withdrawn from most social spaces in the community. During the period of engagement with the Board, there were a conspicuous number of public references made to toxic influencers and after a very disappointing comment from a relevant party, I closed my Mastodon account. Aside from compounding the stress of the meetings, I considered I might be compelled to publicly defend Sonny and compromise our efforts with the Board.

In January, Tobias published Re-Decentralizing Development and seeing the reactions include sentiments like "Cult of Sonny" more or less vindicated my decision to withdraw from social spaces. Some clearly assumed there had been no effort to resolve the matter internally and the spectre of a toxic influencer meant attempts to engage publicly were unlikely to be taken in good faith.

# Good Faith

There are legitimate concerns about an effort to undermine the Code of Conduct (CoC), for the sake of meritocracy. In other words, there are those concerned about different rules being applied to those who contribute more substantially or have more social capital. This is not paranoia; it's the state of justice in many of our real-world societies.

The opposing concern is that the CoC has been used as a tool to defend the status quo or enforce minority opinion as policy. Or as Tobias puts it:

[...] 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.

Code of Conduct reports must be confidential and the decisions of the committee must be unimpeachable; under no circumstance can they become a matter of public opinion.

Unsurprisingly, there are very few situations that justify revealing any participant of a Code of Conduct report. Doing so has resulted in reputational damage such that an uncensored Google search of the name "Sonny Piers" returns pages of tabloid smear and speculation of criminality. Yet in the many months since, there has been no indication that this served the interests of community safety.

Although I acknowledge the community ban has since been relaxed to one year, I would like if we could each appreciate that to be stripped of membership, barred from ever holding a position in the Foundation and permanently banned from all community spaces is to be told, "You are irredeemable". Again, in the time of Sonny's absence, there have been no signs that the safety of the community ever warranted a permanent ban.

The good faith assumption seems to be that these actions were taken to send a message: the Code of Conduct will be enforced, regardless of a person's stature in the community. Unfortunately, if that was the intention, a number in the community have already expressed confusion that this situation received treatment so different from their own.

# Trust and Accountability

I spent a fair amount of time recently deciding whether I would renew my Foundation membership or not. Those in the Foundation working to rectify the breakdown of communication and policy are the reason I decided to stay. However, there are also those in the Foundation who have made me feel an unwelcome bystander to the very public condemnation of a colleague, only be told not to cause a fuss.

I strongly believe the CoCC operated on an unfounded assumption of bad faith: that Sonny Piers is a toxic influence to be immediately and permanently removed from the community. Since July, none of the corroborating signs have surfaced; few have had more contact with Sonny than a short email response, there has been no public appeal to gather signatures, no coup d'état in the Foundation and, with two months left on the community ban, fears of him being exempt from the rules seem moot.

A number of the recent policy improvements were prompted by the findings of the external review commissioned by the Foundation, but I'd like to clarify this was an assessment of whether the Code of Conduct Committee acted within its scope and authority; not a judicial review. The severity of corrective action has not been justified, nor did any review findings or policy changes apply retroactively.

While the Foundation has and will continue to improve, it seems unlikely we will see accountability for the mishandling of a situation that has caused damage to an individual, to the community and trusting relationships. For trust to be restored, we must be assured that Code of Conduct Committee is free from conflicts of interest and is only applied in the interests of community safety.

# Final Thoughts

I don't know what to do about this. I know there are those in the Foundation working very hard to improve the situation and those on the Board aware that they can just ignore criticism until their seat is up for re-election.

The GNOME Foundation is becoming a more important part of the GNOME project every year, but it is still extremely opaque to most of us. If there is a way to educate oneself as a voter I do not know it, and we must accept that has become a serious problem.

We can not have confidence in leaders elected on vague familiarity and then expect accountability from elections separated by two years. And the GNOME Foundation can not build trust in governance by appealing to its own authority.

Best Intentions

Andy Holmes — Mon, 19 Aug 2024 23:32:00 GMT

This is going to be a bit of a sporadic blog post covering XDG Intents, GSoC and few other updates from GNOME goings on.

# XDG Intents

Most end-user platforms have something they call an intent system or something approximating the idea. Implementations vary somewhat, but these often amount to a high-level desktop or application action coupled to a URI or mime-type. There examples of fancy URIs like sms:555-1234?body=on%20my%20way that can do intent-like things, but intents are higher-level, more purposeful and certainly not restricted to metadata shoehorned into a URI.

I'm going to approach this like the original proposal by David Faure and the discussions that followed, by contrasting it with mime-types and then demonstrating what the files for some real-world use cases might look like.

# The Landscape

Let's start with the mime-apps Specification. For desktop environments mime-types are, most of all, useful for associating content with applications that can consume it. Once you can do that, the very next thing you want is defaults and fallback priorities. Now can you double-click stuff to have your favourite application open it, or right-click to open it with another of your choice. Hooray.

We've also done something kind of clever, by supporting URI handlers with the special x-scheme-handler/* mime-type. It is clever, it does work and it was good enough for a long time. It's not very impressive when you see what other platforms are doing with URIs, though.

Moving on to the Implements key in the Desktop Entry Specification, where applications can define "interfaces" they support. A .desktop file for an application that supports a search interface might look like this:

[Desktop Entry]
Name=Contacts
Icon=org.gnome.Contacts
Exec=gnome-contacts %U
Terminal=false
Type=Application
DBusActivatable=true
Implements=org.gnome.Shell.SearchProvider2

The last line is a list of interfaces, which in this case is the D-Bus interface used for the overview search in GNOME Shell. In the case of the org.freedesktop.FileManager1 interface we could infer a default from the preferred inode/directory mime-type handler, but there is no support for defining a default or fallback priority for these interfaces.

While researching URI handlers as part of the work funded by the STF, Sonny reached out to a number developers, including Sebastian Wick, who has been helping to push forward sandboxing thumbnailers. The proposed intent-apps Specification turns out to be a sensible way to frame URI handlers, and other interfaces have requirements that make it an even better choice.

# Terminal Itchiness

In community-driven software, we've operated on a scratch-an-itch priority model for a very long time. At this point we have several, arguably critical, use cases for an intent system. Some known use cases include:

Default Terminal

This one should be pretty well known and a good example of when you might need an intent system. Terminals aren't really associated with anything, let alone a mime-type or URI scheme, so we've all been hard-coding defaults for decades now. See the proposed terminal-intent Specification for details.
Thumbnailers

If C/C++ are the languages responsible for most vulnerabilities, thumbnailers have to be high on the list of application code to blame. Intents will allow using or providing thumbnailing services from a sandboxed application.
URI Handler

This intent is probably of interest to the widest range of developers, since it allows a lot freedom for independent applications and provides assurances relied on by everything from authentication flows to personal banking apps.

Below is a hypothetical example of how an application might declare it can handle particular URIs:

[Desktop Entry]
Name=Wise
Icon=com.wise.WiseLinux
Exec=wise %U
Terminal=false
Type=Application
DBusActivatable=true
Implements=org.freedesktop.UriHandler

[org.freedesktop.UriHandler]
Supports=wise.com;
Patterns=https://*.wise.com/link?urn=urn%3Awise%3Atransfers;

While the Desktop Entry specification states that interfaces can have a named group like above, there are no standardized keys shared by all interfaces. The Supports key proposed by Sebastian is important for both thumbnailers and URI handlers. Unlike a Terminal which lacks any association with data, these need the ability to express additional constraints.

So the proposal is to have the existing Implements key work in tandem with the intentapps.list (similar to the MimeType key and mimeapps.list), while the Supports key allows interfaces to define their own criteria for defaults and fallbacks. Below is a hypothetical example of a thumbnailer's .desktop file:

[Desktop Entry]
Name=Image Viewer
Icon=org.gnome.Loupe
Exec=loupe %U
Terminal=false
Type=Application
MimeType=image/jpeg;image/png;image/gif;image/webp;image/tiff
DBusActivatable=true
Implements=org.freedesktop.Thumbnailer

[org.freedesktop.Thumbnailer]
Supports=image/jpeg;image/png;image/gif;image/svg+xml;image/tiff

The Supports key will always be a list of strings, but the values themselves are entirely up to the interface to define. To the intent system, these are simply opaque tags with no implicit ordering. In the URI handler we may want this to be a top-level domain to prevent things like link hijacking, while thumbnailers want to advertise which mime-types they can process.

In the intentapps.list below, we're demonstrating how one could insist that a particular format, like sketchy SVGs, are handled by Loupe:

[Default Applications]
org.freedesktop.Thumbnailer=org.gimp.GIMP
org.freedesktop.Thumbnailer[image/svg+xml]=org.gnome.Loupe;org.gimp.GIMP

We're in a time when Linux users need to do things like pass an untrusted file attachment, from an unknown contact, to a thumbnailer maintained by an indepedent developer. So while the intent-apps Specification itself is superficially quite simple, if we get this right it can open up a lot of possibilities and plug a lot of security holes.

# Put this in your backpack, mine's full

First a bit of context for the GLib project, which is comprised of three main parts: GLib, GObject and GIO. GLib contains things you'd generally get from a standard library, GObject defines the OOP semantics (methods/properties/signals, inheritance, etc), and GIO provides reasonably high-level APIs for everything from sockets and files to D-Bus and Gio.DesktopAppInfo.

The GLib project as a whole contains a substantial amount of the XDG implementations for the GLib/GTK-lineage of desktop environments. It also happens to be the layer we implement a lot of our cross-platform support, from OS-level facilities like process spawning on Windows to desktop subsystems like sending notifications on macOS.

Fig. 1. A GLib Maintainer

The merge request I drafted for the initial implementation received what might look like Push Back, but this should really be interpreted as a Speed Bump. GLib goes a lot of places, including Windows and macOS, thus we need maintainers to make prudent decisions that allow us to take calculated risks higher in the stack. It may also be a sign that GLib is no longer the first place we should be looking to carry XDG implementations.

Something that you may be able to help with, is impedance-matching our implementation of the intent-apps Specification with its counterparts in the Apple and Microsoft platforms. Documentation is available (in varying quality), but hands-on experience would be a great benefit.

# Workbench and GSoC

Last year, I was invited by Sonny Piers to co-mentor for both Google Summer of Code and Outreachy, which was really one the best times I've had in the community. He also invited a couple of us Workbenchers from that period to the kick-off meeting for this year's projects.

Recently, he asked if I could step in and help out with this year's programs. This is a very unfortunate set of circumstances to arise during an internship program, but regardless, I'm both honored and thrilled.

I think there's good chance you've run into one of our mentees this year, Shem Angelo Verlain (aka vixalien). He's been actively engaging in the GJS community for some time and contributing to better support for TypeScript, including his application Decibels which is in incubation to become a part of GNOME Core. His project to bootstrap TypeScript support in Workbench is going to play an important role in its adoption by our community.

Our other mentee, Bharat Atbrat, has a familiar origin story. It started as an innocent attempt to fix a GNOME Shell extension, turned into a merge request for GNOME Settings, rolled over into porting Workbench demos to Vala and it's at this point one admits to oneself they've been nerd-sniped. Since then, Bharat has been porting more demos to Vala and working on an indexed code search for the demos. As a bonus, we will get a GOM demo that's being used to prototype and test searching capabilities.

# GNOME Online Accounts

The release notes are not yet finalized for GNOME 47, but there are few highlights worth mentioning.

There have been several improvements to the periodic credential checks, fixing several false positives and now notifying when an account needs to be re-authenticated. The notification policy in GNOME 47.beta turned out overly aggressive, so it has been amended to ensure you are notified at most once per account, per session.

Fig. 2. Entirely Reasonable Notification Policy

For Kerberos users, there is rarely any exciting news, however after resurrecting a merge request by Rishi (a previous maintainer) and some help, we now support Linux's general notification mechanism as a very efficient alternative to the default credential polling. If you're using your Kerberos or Fedora account on a laptop or GNOME Mobile, this may improve your battery life noticeably.

The support for Mail Autoconfig and improved handling of app passwords for WebDAV accounts will ship in GNOME 47. The DAV discovery and Mail Autoconfig will form the base of the collection provider, but this won't ship until GNOME 48. Aside from time constraints, this will allow a cycle to shake out bugs while the existing pieces are stitched together.

The Microsoft 365 provider has enabled support for email, calendar and contacts, thanks to more work by Jan Michael-Brummer and Milan Crha. This is available in GNOME OS Nightly now, so it's great time to get in some early testing. We've made progress on verifying our application to supports more organizational accounts and, although this is not constrained by our release schedule, I expect it to be resolved by GNOME 47.

# Acknowledgements

Many thanks again to the Sovereign Tech Fund and everyone who helped make it possible. I would also like to express my appreciation to everyone who helps me catch up on the historical context of the various XDG and GLib facilities. Even when documentation exists, it can be extremely arduous to put the picture together by yourself.

Fig. 3. Ideal Psychological and Emotional State

Until next time, stay sweet.

GNOME 46 and Beyond

Andy Holmes — Tue, 11 Jun 2024 18:27:00 GMT

With GNOME 46.2 released, it seems like a good time to write a post about goings on in GNOME Online Accounts and other STF-funded initiatives. There's a lot to be excited about this cycle and most of it is leading to more improvements in the near future.

# GNOME Online Accounts

A lot happened in GNOME 46 for GNOME Online Accounts, including two new providers, a port to GTK4 and Adwaita, authentication in the desktop browser, and a large refactoring towards contemporary platform conventions.

The new WebDAV and Microsoft 365 providers contrast quite a bit, although both made progress in the general direction we want to move. The existing Nexcloud provider was a good starting point for WebDAV, but support for more implementations and auto-discovery were important goals for our push towards open protocols and local-first principles.

# WebDAV

The WebDAV provider seemed like it would be fairly straightforward, however feedback from the community has shown that several popular services like Fastmail and mailbox.org offer support for features like custom domain names and app passwords restricted by content type. These are great features, but not supported by a naive implementation of standard service discovery.

The large refactoring in GNOME 46 de-duplicated a lot of code and is much easier to use, but a lot of the account setup process is still tightly coupled to the user interface. The new work being done to support more service configurations and improve the user experience is separate from the provider code, which has already led to the easy integration of some nice features:

In the video above, you can see the implementation of Mail Autoconfig at work detecting settings for Fastmail from the email address, in the otherwise unchanged Email setup dialog. I'd like to thank Tyler and the rest of the development team at Fastmail for extending me an account for additional testing this cycle. By design, Mail Autoconfig doesn't need authentication, but this account was very helpful while improving support for content-restricted app passwords.

These app passwords are especially relevant to WebDAV, which received a few adjustments to adopt an internal API compatible with the Mail Autoconfig implementation. While the WebDAV setup dialog hasn't landed the same UI feedback improvements yet, there is a work-in-progress that does:

In this video, you can see an early prototype for a goal of a lot of this work. Thanks to the research and work of Éloi Rivard we have an excellent whiteboard for Generic Service Providers, detailing a large amount of the subject matter. The immediate goal then is to offer an account type that's easy to set up, supports the common set of services (mail, calendar, contacts and files) and adapts to the available services using open protocols and standards.

We still have longer-term changes planned to support a sandbox-friendly ecosystem, but it's not yet clear what form GNOME Online Accounts will take or how applications will interact with it. For this reason, all the new code supporting Mail Autoconfig and WebDAV was written for potential reuse later, without investing in becoming yet another Accounts SSO.

# Microsoft 365

Much of the recent work on GNOME Online Accounts was funded by the Sovereign Tech Fund, while the Microsoft 365 provider is the work of Jan-Michael Brummer. The initial support includes access to OneDrive with Files and GVfs, with support for email, contacts and calendar planned for the near future. While our focus remains on open protocols and local-first principles, it's still a goal to support services that the people use in their work and provide benefit to the community.

Something interesting the project gained from Jan's work is the first OAuth provider with support for user-provided client IDs. Currently, every distributor and fork of GNOME Online Accounts has been using the GNOME Foundation's client IDs for OAuth providers. This can be problematic depending on the terms of service and restrictive for those using enterprise or organizational accounts.

Unfortunately, the first iterations of the setup dialog did not result in a good user experience. Microsoft's services come with their own concepts and terminology, which really resulted in a lack of clear direction in the design of the interface during an already busy release cycle. The tight coupling between logic and user interface did not help here either, as evidenced by the double-modal:

The amount of feedback and issues reported has been the most help here, as we learn how Microsoft 365 is being used by the open-source community in both personal and work-related environments. Support for more services like email, calendar and contacts are planned, and hopefully some better support for organizational accounts.

# Orca and Spiel

Something I am thrilled to have the opportunity to take part in is Spiel, a new speech synthesis service by Eitan Isaacson that's a bit reminiscent of MPRIS. New speech providers can be easily written in C, Rust or any other language binding and libspiel will aggregate them for the client.

An interesting difference with Speech Dispatcher is that while the speech provider takes responsibility for speech synthesis, the client application takes responsibility for the audio output. Internally, the speech provider returns a file descriptor over D-Bus and GStreamer is used to output the audio on the client side.

While Spiel does have some exciting possibilities outside of screen readers, including new synthesizers like Piper, you may be surprised to find the speech rate that many users operate a screen reader at. Léonie Watson has an excellent blog post titled Notes on synthetic speech, with plenty of audio clips and insights into how screen readers are used by real people.

I was fortunate enough to have the opportunity to integrate Spiel into Orca, which was a great learning experience and re-sparked my interest in accessibility in general. Something else to watch out for is Matt Campbell's Newton project, bringing a modern accessibility stack to Wayland.

# Acknowledgements

I'd like to again thank the Sovereign Tech Fund for investing in the GNOME project. Their targeted funding of infrastructure and accessibility has empowered a lot of overdue improvements for open source and the GNOME platform.

I'd also like to thank the development team at Fastmail, who upon request graciously granted us an extended account, to continue testing support for their service. The support staff at mailbox.org also extended a trial period as a show of good faith. It's been really encouraging to have these companies show support for the community, thank you!

As always, GNOME's community of contributors and users have been the most help, with diligent reporting, code reviews and advice. There are so many things happening in open source, I really wouldn't be able to keep up without all your help.

GNOME Online Account and the STF

Andy Holmes — Fri, 15 Dec 2023 18:27:00 GMT

One of our goals for the Sovereign Tech Fund is to modernize platform infrastructure, in line with the mission to support security and resilience in open source software. For GNOME Online Accounts, this meant tightening up the code base and shifting focus to prioritize open protocols.

A significant portion of the backend was refactored and tested in tandem with the GNOME Settings side of Online Accounts. By working with development tools like AddressSanitizer we identified and fixed a number of memory and type safety issues in both projects and helped to ensure the resiliency of any new code.

# What did we do

The first thing we wanted to do was get a general WebDAV provider merged. This work was a multi-phase community effort and the majority of the work as part of the STF was adding and testing more thorough and resuable code for DAV discovery and configuration.

The new WebDAV provider then became a base for the Nextcloud provider, which is now simply a branded version.

Another big step to improving reliability and maintainability is updating to the latest dependencies and industry conventions. This meant first supporting OAuth 2.0 in a standard browser so, for example, when you log into a Google account you're doing it with your preferred, trusted browser. This allowed us to remove the old WebKit2 dependency and port to GTK4 and libadwaita.

Although the user interface for adding an account is simple, each account type needs its own, so GNOME Online Accounts has traditionally had a strange API and behavior. In the GTK3 days we used modal dialogs and nested loops in ways that really didn't work out. Nowadays we often approach user tasks like "Pick a File" with simple task-based APIs and now GNOME Online Accounts does, too.

# The Future of Online Accounts

When we're talking about Single Sign-On with GNOME, we're talking about authenticating an account once and making it available to multiple desktop applications. You log into Nextcloud, then when you open GNOME Contacts or Calendar it can access your data using the account credentials. Aside from other hurdles in the project, we have no ability to enforce any real trust model, let alone selectively by application or content type.

The future of GNOME Online Accounts then has less to do with accounts and services than it does with security and content. A user shouldn't have to worry about a calendar app scraping their e-mails and the developer shouldn't have to care about OAuth 2.0 or RFC 5545. Tracker provides a sandbox-friendly data storage framework with a feature set we can build on to give users more control and developers less legwork.

Other aspects of the project have a less certain future. libgdata is currently without a maintainer and having the GNOME Foundation's provider client IDs used almost universally has left us in an awkward relationship with service providers like Google and Microsoft.

This doesn't mean GNOME Online Accounts is going away, but that we're re-orienting to best provide control to users and simplicity to developers. Prioritizing open protocols like WebDAV and modernizing the code base are first steps towards less dependence on closed services and tighter security. A few of our next steps will include new libraries that provide controlled access to content (e.g. contacts) without exposing account credentials to applications.

# Corporate Users

We'd like make a point of inviting our corporate users to reach out and contribute. Some are already in contact or have contributions waiting for review and we thank you for your patience.

Since the focus moving forward will be on open protocols, we will be relying more on contributions from the community to help maintain support for closed services. If you are a business or work for a business that benefits from integration of a proprietary service, consider sponsoring an employee or a developer in the community for support and maintenance of these services.

Contributing upstream is a great way to give back and shows you're an active part of an industry embracing open source, especially if you are the service provider. The GNOME Foundation is always proud to announce collaborations with other parties in its press releases, which reach many other corporate partners and related markets.

# Acknowledgements

We'd like to thank the Sovereign Tech Fund for investing in GNOME Online Accounts. With most maintainers stretched thin, the opportunity to get everyone together for video meetings and the time to take in a whole new codebase would not have been possible without their support.

We'd also like to thank the many members of the GNOME community who lent their experience and ideas, as well as Christoph Wurst from Nextcloud who joined in on a meeting. The work on this project really wouldn't be possible without the combined talent of various backgrounds.

Mentoring in Open Source

Andy Holmes — Thu, 31 Aug 2023 06:09:00 GMT

This year, I was invited by Sonny Piers to be a co-mentor for the GNOME Foundation, working on platform demos for Workbench. I already contribute a lot of entry-level documentation and help a lot of contributors, so this felt like a good step in a direction I've been heading for a while.

# Internships

Together, Sonny and I mentored three interns; two by way of Google Summer of Code (GSoC) and a third for Outreachy. Both are international programs providing a great opportunity for newcomers, but differ in some important ways.

# Google Summer of Code

Google Summer of Code has been around for a very long time, although I've been around long enough to remember when it started, and how it helped change the public image of open source. Google's program is well developed, while at the same time being mostly hands-off, leaving most of the planning and direction to the mentors.

Something that did influence our choice of applicants was the requirement that interns be open source beginners, which I feel doesn't account for those who could benefit from more advanced mentoring. Of course, we had plenty of applicants and I have no regrets about our selection.

# Outreachy

Outreachy is a newer program and one that actually started as an initiative of the GNOME Foundation. It is focused on those that are underrepresented in the industry, and fostering a positive feedback loop to address this ongoing issue.

In contrast to Google's program, Outreachy is not limited to students or developers, which is important when you consider the barriers to education and lack of opportunity its applicants often face. The program also includes prompts and goals, both for mentors and mentees, that help make these internships more engaging.

The infrastructure for Outreachy is kind of unassuming at first, compared to Google's sleek and streamlined website. Once you're a few weeks into the program though, you realize they really are a lot more focused on genuine mentorship. Nothing about your interaction with the coordinators is impersonal or superficial.

Marina Zhurakhinskaya deserves special mention here, and even if you haven't heard the name before, you have heard the names of those whose lives she touched. Although I never had the honour of working with her myself, it's impossible to ignore how we all continue to benefit from her contributions.

# People

I should first thank Sonny for the opportunity to participate as a mentor for the GNOME Foundation. This is not something I've been able to do in a formal way since high school when I was allowed extra classes to assist younger students in the electronics program.

We've all been in the position where you really just need someone to answer the question, "Okay, but how does it actually work?". Being a part of the "Oh, now I get it!" moments is an unparalleled experience for me. I'm really grateful I had the chance to be involved in this way again.

# Akshay Warrier

Akshay is going to do great things in open source and I think he really gets community-driven software. He's one of those people that renews your excitement for open source.

Aside from the contributions he's made to Workbench as part of his internship, I was really excited to see him appear at our yearly GNOME Shell Extensions workshop. I know he had a fantastic time at GUADEC and the way he talked about it made it obvious how much importance he places on people.

I think we'll see more of Akshay and, one day, I think he could make a really great mentor himself.

# José Hunter

José comes up with some great ideas, and he's quick to jump in and get them implemented. Given the right circumstances, I think we might see him do some really cool things in the community.

He's blogged about privacy and the encroach of corporate interests, and it's hard not to think this encouraged his involvement in open source. I think he has a natural impulse to form his own opinions about the technology he uses and employs, and an honest interest in projects related to his hobbies like libmanette.

I hope José sticks around after his internship is complete, because he has a personality that has served the community well in the past.

# Sriyansh Shivam

Sriyansh displayed an aptitude for development early on, but also a habit of responding to feedback in a really constructive and professional way. That's a hard thing to do sometimes, and he really has the drive for self-improvement.

We spent a fair amount of time working through a series of demos about the model-view-controller pattern together, and I really enjoyed that. These demos covered everything from GListModel and GtkListBox, to the newer view widgets like GtkColumnView. These are very popular in GTK4 applications, and often quite complex, so I'm quite proud to see the results of his hard work.

I'm not sure we really had a chance to see his full potential, and I hope he gets the opportunity to take on a longer more challenging project.

# The Future

I hope to have the time and opportunity to mentor again, and next time I would like to apply myself in a more thoughtful way. I write a lot of entry-level documentation for free software, but the feedback is far more asynchronous and has to be applied more statistically.

Having spent time with several mentees over an extended period of time was a good way to learn a lot. Sonny and I had some good conversations about what seemed to work in retrospect, which was very enlightening. I would really like to try mentoring again, but next time with a more developed strategy.

I will say that co-mentoring is definitely something we should encourage more as a community. It's difficult to be confident of your take on an interpersonal relationship, and having someone to balance that turned out to be invaluable to the mentorship.