With all the algorithms out there vying for our attention–decidedly not showing us content based on what is healthy for us or what we might find enlightening–I’m more and more drawn to human curation. Content suggestions from the creator of the thing I’m already looking at, not from a profile of my overall browsing habits. Personal recommendations from people I interact with, like in the old days when your “social network” meant your friends and their friends.

Another aspect of a bookmarks list that I like is that it’s static. Sure, I’ll update it when I find something new that I think should be on it, but it’s not a feed intended to get clicks once and then fade into memory. (In fact, I’ve made it re-shuffle the list every day so the most recently added links aren’t always at the top or bottom.) It’s there to be happened upon by chance, by anyone who might visit my site and want to see more stuff like it. There’s no urgency to get it clicked on, no disappointment in low engagement numbers. It’s just there.

In an age of large language models and generative AI, in the face of machines that can provide the appearance of human interaction without any of the substance, it’s going to take effort and intentionality to maintain healthy, human-centered spaces in the online world.

So I hope this trend catches on. I want an internet more full of rabbit trails and branching paths than endless scrolls. So find that oft-used reference page. Dig up that favorite little game from your childhood, or that blog post you always come back to. And post a list of links somewhere. The future of the internet is waiting.

My Bookmarks

My public bookmarks list! A collection of stuff I've found interesting, useful, or thought-provoking.

Why a New Style?

The vector renderer in libshumate uses the MapLibre Style Specification format. MapLibre is a widely-used open source library for rendering maps, so there are plenty of existing styles available for it. However, most of them are designed to be basemaps, ideal for displaying data on top of them. They often use muted colors and don’t show much detail, particularly the dark styles. Our use case is different: as a maps app, the style itself is the main focus of the map. It needs to be clear and easy to read while containing all the information people expect from a street map.

OSM Liberty, the style that the Experimenal Map mode used in 45, wasn’t bad for this purpose. It has icons for many types of places, it uses color to distinguish different types of roads, and it has the detail we need. But it’s not a perfect fit. It has no dark variant, which is an important part of the GNOME platform. It also doesn’t incorporate some newer techniques like localization, highway layering, or complex text formatting. Sure, we could add those features, but at that point we’re basically making a new style anyway.

Besides, I wanted to make a style that’s unique to Maps, to give it a distinctive identity. It should be something we can tweak and improve over time, that’s designed to be the best possible map for our app.

Design Goals

I started out with a few goals in mind:

• Compliance with GNOME’s HIG. The map style should follow GNOME’s Human Interface Guidelines. This encompasses typography, color scheme, icons, dark mode, accessibility support, and overall design ethos.
• Worldwide usefulness. The map style should be suitable for use everywhere, not just in a few regions or cultures. For example, a purely car-centric map would be of less use in much of the world.
• Compatibility with libshumate. There are a few limitations to the vector renderer. In particular, it doesn’t yet support text outlines, so label colors need to be chosen carefully to be readable on any background.

On a technical level, the style was very much inspired by the OSM Americana project. They have been pushing the limits of what MapLibre can do, and their style is much more than a static basemap. It’s a dynamic, data-driven map that brings relevant information to the forefront with localized names, highway shields, and more. While GNOME Maps looks much different visually, it uses many of the techniques that OSM Americana pioneered.

One such technique is simply the use of code generation. Rather than being a static JSON document, like many existing styles are, Americana is generated using JavaScript. This allows for much more complex logic, such as the loops that enable correct highway layering.

Making the Style

I started with the high-level features, like water, borders, and place labels. Without those, it’s hard to even navigate the map. I originally used the same color palette we use for app icons, but many people told me it was much too saturated, so I toned it down quite a bit.

Next was roads, which are the most complex part of the style and took a lot of iteration to get right. They need to be the right width at each zoom level, and the colors should clearly indicate the type of road without the color differences being too extreme. Bridges and tunnels should be indicated, and the labels need to be readable no matter the style of the road. And on top of that, there’s pedestrian and cycle paths, which I wanted to be visually distinct without feeling less important than vehicle roads.

Then there’s buildings, which are a bit simpler. They should be a neutral color, but still stand out from the background. I decided to make them visible, though faint, at zoom level 13. It’s not too useful at that zoom level, but it gives otherwise empty areas a bit of texture. And at higher zoom levels, they’re more prominent.

Landcover was tricky because it adds more background colors to the map. It wasn’t hard to make it look good on its own, but it was hard to make it work with the other features without reducing contrast.

Railways were also important to me. Most other maps don’t show them very prominently, but I think it’s valuable to remind people of their transportation options, and railroad tracks can be useful landmarks. While most maps use gray, I gave them a distinctive pink color. And then to continue the transportation theme, Marcus Lundblad added ferry lines and gondolas. So no matter how you’re getting around, hopefully Maps can show you the way!

Points of interest (POIs), like shops and restaurants, were the last major feature. They required some work on the libshumate side, but now we can use symbolic icons from the Adwaita icon library. Many of the icons I needed were already there, and Jakub Steiner from the GNOME design team made a bunch of new ones for us. The lack of text outlines was a bit of a problem when it came to coloring the icons, but I think I found a good balance for contrast.

Highway Shields

Another awesome feature of OSM Americana is highway shields: the symbols that distinguish different route networks, such as the US Interstate system. Fortunately, most of their work was reusable. I had to port the drawing code to C, but the logic and the SVGs were already there. Thanks again to all the Americana contributors for making this possible!

Available in GNOME 46!

The new style is available in the “Experimental Map” mode in GNOME 46 or the nightly flatpak. Give it a try and let us know what you think! Now that it’s merged, bugs or feature requests related to the style can be submitted to the Maps issue tracker.

The vector renderer has been three years in the making, so I’m extremely excited to finally see the fruit of all my effort!

Overzooming

One of the major benefits of vector tiles is that, unlike raster (image) tiles, we can scale them up without making them blurry. This means that, after a certain zoom level, it’s not really useful to keep splitting the data into smaller and smaller chunks–we can just take a lower zoom level and scale it up.

This has benefits throughout the stack. Offline maps will take a lot less space because we won’t have to store so many different levels of detail. Also, since each zoom level contains four times as many tiles as the one before it, level 18 for the whole world contains over 68 billion tiles! But level 14 contains “only” 268 million. That’s still a whole lot, but it’s small enough that, with a powerful enough computer, we can generate them up front and serve them with a much simpler server than raster tiles, which must be generated on demand. The pre-generated tiles are about 80 GB. If you’d like to know more about this process, check out Planetiler or watch out for a future blog post!

Symbol Collision

The symbol collision detection that I described in my previous post worked well, but had some drawbacks. Primarily, it wasn’t flexible enough to support all the text layout features I want to implement from the MapLibre spec.

The problem was that the R-tree was built ahead of time and persisted between frames, so it had to contain every symbol in the visible area and every way that each one could rotate or be repositioned. This would have made the code extremely complex if, say, I wanted to add the text-variable-anchor property, which allows labels to move around to get the best chance of not colliding with another label. How would the R-tree know which placement of the label is the current one?

So I changed the R-tree to be re-built every frame. Only rectangles that are currently visible are included in the tree, so the code to check whether a rectangle collides is much simpler. Surprisingly, the new approach actually increases performance, despite constantly rebuilding the tree. Only visible rectangles have to be checked against on each lookup, and the rectangles are smaller because they don’t have to account for every possible rotation of the label, which makes the R-tree method more effective. Here’s the visualization of the new technique:

Icons

Following the symbol collision changes, I implemented icons in symbols. This includes both the icons in places’ labels and things like the one-way arrows on streets. It would have been much more complicated to do correctly with the old collision code, but now it works pretty well. Here’s a screenshot:

Expressions

A huge part of the MapLibre spec deals with expressions and data-driven styling. It’s one of the things that make vector tiles so powerful: we can customize the map in new and creative ways without downloading a whole new set of tiles from the server.

Expressions allow style authors to make styling decisions based on the characteristics of individual features, such as giving tunnels a dotted line casing or choosing an icon based on a point of interest’s specific subclass.

The OpenStreetMap Americana project has been pioneering many interesting new uses of expressions. They have support for internationalization, even showing a city’s local name underneath its name in your language if it’s different. They also have highway shields, which are the “icons” that distinguish different route networks, such as the US Interstate system. These use fairly complicated chains of expressions, so to get these features in libshumate I’ll need to implement more of the expressions spec.

I’ve started with the case and coalesce expressions, which let us use conditions and create fallback styles, and let and var, which make it easier to change style configurations and keep the style organized. I also added some basic string functions like concat and downcase as well as mathematical operations.

Future Work

I’ve created a documentation page cataloging the state of our MapLibre spec implementation. There’s a lot of red X’s at the moment. But many of them, including the most important ones, will be fairly straightforward to implement.

I’ve also made some improvements to performance–including Sysprof integration–but that’s a subject for another blog post. I’ve also started working on a new map style, which will also get a blog post when it’s a little further along.

But most importantly, the vector renderer is getting to a point where it’s usable with a real style–you might have noticed the screenshots in this post use OSM Liberty instead of the old testing style, and it looks pretty good! So the next step is to get GNOME Maps ready to use the vector styles. It will start as an experimental feature, but the goal is to get it to a point where it can become the default.

Thank you to everyone who’s encouraged my maps obsession over the years, given me feedback on my map style, reviewed my merge requests, and contributed on Sponsors. I’m looking forward to another exciting and hopefully eventful year of map development!

Securing Your Wallet

Cryptocurrency is like a giant warehouse full of locking donation boxes. Anyone can drop money in a donation box, but only someone with the key can take the money out. Crypto wallets are similar. You can spend money from a wallet only if you have that wallet’s key, which is like a password generated for you when the wallet is created.

However, having the wallet’s key is different from being the wallet’s legal owner. If someone steals the key, as far as the technology is concerned, they have full rights to spend its money. So the “unbreakable” security of cryptocurrency all depends on keeping those wallet keys safe. If, say, they’re backed up to iCloud and someone hacks your account there, or any number of other things happen to them–cybersecurity is really complicated–all the cryptography in the world can’t help you.

Is It Even Your Wallet?

Making the issue worse is that many people who hold cryptocurrency don’t even have their own wallets. Instead, they hold their currency through an exchange, which is basically a less-regulated version of a bank. The exchange has its own wallets, and they keep their own records–just like a bank–of which customers own what funds. Hopefully, the exchange keeps better track of their wallet keys than most individuals could hope to. However, holding so many people’s funds in their own wallets also makes them a juicy target. Instead of wallets containing one person’s funds, a hacker could steal wallets with thousands of people’s money. If that happens, the exchange probably won’t be able to cover withdrawals and, without FDIC insurance or any other typical legal protections, customers are out of luck.

Good Old-Fashioned Scams

Some of the “hacks” are really just scams. Nothing is being hacked, everything is working as intended: to steal money from victims and give it to the scammers. Tons of new coins are pump-and-dump schemes, where a cryptocurrency is marketed by its creators so they can sell it to the marks they’re hyping it up to–only to run away with their profit, leaving the abandoned coins to rot, worthless.

Ethereum and DAOs

Ethereum is a blockchain that gets even more complicated. With it, you can create decentralized autonomous organizations, or DAOs. Just like a non-profit, members of a DAO can vote on what to do with the organization’s funds. But instead of bylaws, a DAO is governed by code. If bylaws are deeply flawed, a judge can overrule them. But if the DAO code is flawed, there is no recourse. If it allows a hacker to steal all the funds for themselves, there’s nothing to stop them.

What Is Security?

In the narrow case of preventing people without a wallet’s key from spending that wallet’s money, yes, cryptocurrency is secure. But that’s not what we want. When we ask for “security,” we want to be assured that our money will not be lost, that malicious people won’t be able to interfere with our lives, and that the products we use will live up to their promises. These are social and legal questions, and technology alone cannot solve them.

Now that the basics are done, I’m almost ready to call it 1.0. I still need to figure out how to integrate it with Meson better, because there are issues in some cases with the order that things are compiled. There’s also a couple more features I want to include, and I have a milestone to track them in GitLab.

After the official 1.0 release, I have a number of ideas for where to take Blueprint next.

IDE Integration

IDE integration has been a goal from the beginning, but there’s more to do still. I’d like to add a symbol outline, so you can visualize the widget tree and jump to the right part of a large file. It would also be nice to be able to control-click an identifier and jump to that object.

I want to improve the in-IDE documentation, especially by adding docs to keywords when you hover over them. For example, when you hover over template, it will give you a refresher on how templates work. Finally, I want to add a source code formatter. Most languages have these, and many developers and projects rely on them to help keep code readable.

In addition to the GNOME Builder integration, I have an experimental VS Code extension that I need to clean up, make production-ready, and publish. Thanks to the Language Server Protocol, the vast majority of the code is not specific to any one IDE and actually resides in the compiler, not the extension. Still, there is some “glue code” and another syntax highlighter to be written.

Documentation & Tutorials

Right now, Blueprint’s documentation is quite sparse. There’s an overview, a tutorial on porting existing projects, and a long list of examples presented mostly without comment.

I’d like to expand the documentation with a complete explanation of what Blueprint does and how it works. I also want to create walkthrough of how to create a simple app from scratch using Blueprint, without prior knowledge of GtkBuilder required. That way, developers wanting to get into GNOME/GTK programming can start out with Blueprint if they want.

Reactive UI programming

I mentioned reactive programming in my last post about Blueprint, and I want to expand on that idea because I think it’s really powerful.

A bit of theory, and some GObject details

The following is some background on programming language concepts, which I find interesting; you can skip this section if that doesn’t interest you.

In the declarative programming paradigm, you describe the expected result of a computation. This is in contrast to imperative programming, where you outline the exact steps of a computation. For example, a SQL query describes what data to fetch and how to aggregate it, but leaves the loops and table lookups to the database to figure out.

Reactive programming is a type of declarative programming where a value can depend on other values and be updated automatically when they change. In reactive programming, a = b + c is not an assignment that executes at a point in time, but rather an invariant that holds as long as a exists. When either b or c changes, a automatically changes to match.

This paradigm is particularly fitting for user interfaces, which usually need to continually reflect the state of some underlying data model. When the data changes, the UI always needs to update with it. Have you ever had a giant, messy update() method in your UI code that you call whenever the data changes? That’s the imperative programming solution to a problem that’s inherently reactive.

Web frameworks have been using more-or-less reactive approaches for a long time. React (of course), Angular, Vue, and Svelte are well-known examples. Although they work in different ways, all four use templates to generate an HTML page from data, then keep the page updated when the data changes. They’ve managed to make this work, but JavaScript doesn’t always play nice–there are well-known performance issues with recalculating the DOM tree, and nested data structures generally don’t trigger updates.

But it turns out GObject has had a critical reactive programming feature since before I was born¹. It’s the notify::* signal, which invokes a callback whenever a GObject property changes.

Gtk.Expression is new in GTK 4. An expression can be a constant, a property lookup, or a user-defined function, and expressions can be composed with each other. Expressions can be watched, so that a callback is invoked whenever any input of the expression changes. They can also be bound, so that when those inputs change, a property is updated with the new value of the expression.

You can probably see where reactive programming fits here. Instead of updating the UI by writing tedious imperative code, you can simply declare expressions that update it automatically. No more giant update() methods!

Reactive programming with Blueprint

Here’s how it would work in practice. In your code, you’d define properties for your data. In the matching blueprint file, you’d reference those properties using the bind keyword, which creates a reactive expression.

Some use cases are simple.

Spinner {
  visible: bind MainWindow.active-http-request.pending;
}
Label status_code {
  label: bind MainWindow.active-http-request.status;
}

Some are a little more complex.

Label map_scale_label {
  label: bind (string) zoom_level_to_scale_label(viewport.zoom-level);
}

But with an expanded expression system, you could even do this:

/* Works by generating an expression and binding it to main_stack.visible-child */
Stack main_stack {
  if MainWindow.content-list.n_items() == 0 {
    Adw.StatusPage {
      /* ... */
    }
  } else {
    ListView {
      model: bind MainWindow.content-list;
      /* ... */
    }
  }
}

Implementation

The simpler expressions–constants, property lookups, and callbacks–already exist in GTK and just need matching Blueprint syntax. I’m hoping to implement them soon.

The more advanced reactive expressions will require a helper library (don’t worry, blueprint files that don’t use features from the library won’t need to link to it). Of course, writing a new expression library is a lot more work than just adding syntax to the compiler, so this is a bit of a “stretch goal”.

Making this happen

These plans will likely take well over 100 hours of work to complete. I’m a college student, so this represents a significant investment of my time. If you’d like to sponsor this work, I’d be incredibly grateful! Sponsorships really do help me justify spending more time on Free Software instead of things that pay by the hour :)

But, sponsorships or not, this is something I’m really excited to work on. Language design fascinates me, and developer experience is something I think is really important for any platform. The GNOME ecosystem is great to work with, and the community is creating some awesome stuff that I’m grateful to be a small part of.

Displaying a map

ShumateSimpleMap is designed to work out of the box with very little code.

Shumate.SimpleMap map { }

<object class="ShumateSimpleMap" id="map"></object>

map_source = Shumate.MapSourceRegistry.new_with_defaults().get_by_id(Shumate.MAP_SOURCE_OSM_MAPNIK)
map.set_map_source(map_source)

This code will get you a map widget with the default OpenStreetMap style. (Keep in mind that this style is only available for testing, or with permission from the OSM Foundation to use their tile servers). It also contains all the widgets you’d expect in an embedded map: zoom buttons, license/copyright information, and a scale.

Adding a Marker

You can create a marker layer, then add a marker to it:

Shumate.Marker marker {
  latitude: -48.8767;
  longitude: -123.3933;
  Image {
    icon-name: "view-pin-symbolic";
  }
}

<object class="ShumateMarker" id="marker">
  <property name="latitude">-48.8767</property>
  <property name="longitude">-123.3933</property>
  <child>
    <object class="GtkImage">
      <property name="icon-name">view-pin-symbolic</property>
    </object>
  </child>
</object>

viewport = map.get_viewport()
marker_layer = Shumate.MarkerLayer.new(viewport)
marker_layer.add_marker(marker)
map.add_overlay_layer(marker_layer)

Markers aren’t restricted to just icons. They can contain any widget you want, even containers with multiple children or interactive widgets like buttons.

Setting the Viewport

The “viewport” refers to the displayed location of the map, its zoom level, rotation, etc. You can use the Shumate.Viewport methods to change the map’s viewport.

viewport.set_location(-48.8767, -123.3933)
viewport.set_zoom_level(3)

Accessing Internal Children

ShumateSimpleMap exposes internal children “compass”, “license”, “scale”, and “map”. You can use this, for example, to add extra license text:

Shumate.SimpleMap map {
  [internal-child license]
  Shumate.License {
    extra-text: _("Additional data from Wikipedia");
  }
}

<object class="ShumateSimpleMap" id="map">
  <child internal-child="license">
    <object class="ShumateLicense">
      <property name="extra-text">Additional data from Wikipedia</property>
    </object>
  </child>
</object>

You can also overlay your own widgets over the map. Just add them as children of the ShumateSimpleMap, and use the halign and valign properties to position them (just like a Gtk.Overlay):

Shumate.SimpleMap map {
  Gtk.Button {
    label: _("Open in Maps");
    halign: start;
    valign: start;
    margin-start: 6;
    margin-top: 6;
  }
}

<object class="ShumateSimpleMap" id="map">
  <child>
    <object class="GtkButton">
      <property name="label">Open in Maps</property>
      <property name="halign">start</property>
      <property name="valign">start</property>
      <property name="margin-start">6</property>
      <property name="margin-top">6</property>
    </object>
  </child>
</object>

using Gtk 4.0;

template MyAppWindow : Gtk.ApplicationWindow {
  title: _("My App Title");

  [titlebar]
  HeaderBar header_bar {}

  Label {
    styles ["heading"]
    label: _("Hello, world!");
  }
}

Blueprint is a markup language that compiles to GtkBuilder XML. It’s designed to reflect GTK’s widget model in a straightforward, readable syntax, and is capable of almost everything GtkBuilder is. The compiler catches many types of errors early, so you can iterate faster and spend less time debugging.

Switching a project is simple: the compiler runs as part of your build, and your code stays the same. The interactive porting tool will walk you through most of the process.

The GNOME Builder plugin is a work in progress, but it provides completion, docs, diagnostics, and syntax highlighting. Here is my Builder branch if you want to try it out. I’m also working on a VS Code extension, but it’s not ready yet.

Future Plans

I plan to introduce reactive programming to Blueprint using Gtk.Expression, a feature that already exists in GTK 4. If you’ve used one of the half-billion Javascript frameworks out there, you’re probably familiar with reactive programming. In essence, it syncs your UI (view) with the underlying data (model) automatically, rather than imperatively updating the UI whenever the data changes.

To give a concrete example, you’ll be able to write this in your blueprint once:

Label file_size_label {
  label: bind this.item.file-size;
}

instead of this in your code every time the file size might have changed:

this.file_size_label.label = this.item.file_size;

All you have to do is make file-size a GObject property (not just a property or field in your chosen programming language). This is so it gets a notify signal.

There’s even more potential to expressions. Arithmetic and boolean operations, ternary/match statements, and function calls are all on the roadmap. In other areas, I plan to continue polishing the developer tooling, writing documentation, and examining how y’all use Blueprint in real apps so I can make it even better.

Developer Experience

This project is an exercise in developer experience. I’ve written about Linux platforms before, and good developer tooling is a critical part of any platform. Without app developers, you have no ecosystem. We want to give our developers everything they need to help our platform grow. Toward that end, I’ve put most of my effort in Blueprint toward good error checking and a comprehensive language server.

That’s probably why GNOME Maps fascinates me so much, and why I’ve been contributing to it for three years now. And it’s why I’m thrilled to announce something I’ve been dreaming of for those three years, and working on for the past 8 months: A vector tile renderer for libshumate, the library that will eventually be powering Maps.

What are vectors, tiles, and vector tiles?

Maps currently uses raster tiles. The map is stitched together from static, unmodifiable photos downloaded from the map provider. Vector tiles contain the actual map data: what area the park covers, what the name of the café is. They contain geometry, not pixels, hence vector tiles.

Because raster tiles contain pixels, they’re ready-made to display on screen. Vector tiles don’t contain pixels, so they need to be converted. This process is called rendering. The advantage of doing our own rendering is that we can control what the map looks like: change the colors, choose which language we want, and decide what places to show or hide. The disadvantage is that rendering is complicated–it’s taken me 8 months and 3 different prototypes to get it just right!

Slide to compare

Not everything is implemented yet. I still need to support labels, icons, and higher zoom levels, then spend some time polishing and testing.

What does this mean for Maps?

Not much in the short term–libshumate won’t be ready for another release or two. Not only are we adding a bunch of features, we’re also redesigning some of the API and porting to GTK 4.

But when it’s finally finished, we’ll be able to support a number of oft-requested features:

• Showing place names in your native language, where avaliable
• Downloading maps for offline use (technically this could be implemented now, but raster tiles are too large for it to be practical)
• Rotating the map without rotating the labels with it
• Smooth zooming without pixelation
• Getting rid of “What’s Here?” in the right-click menu. You’ll just click (or tap) a place instead.

Some of these features will work out of the box, and some will need additional work, but I hope to eventually implement all of them.

Stay tuned!

There’s lots more work to do to get libshumate and the vector renderer ready. I’m a student and I have a part-time job, so no promises on the timeline, but I hope to have another update in the coming months with lots of exciting progress!

“Linux Is Not A Platform”

This is the general sentiment I hear from developers. But “Linux is not a platform” is a very vague statement. What is a platform? What is Linux?

The clearest example of a platform is iOS. Par for Apple, it’s tightly controlled and managed–not something we’d ever want, but helpful for extrapolating a definition. iOS as a platform consists of many things. It’s a set of libraries, system services, toolchains, and hardware. But it has less tangible components, too: APIs, best practices, Human Interface Guidelines, and even user expectations are all part of the iOS platform.

If that’s what makes up a platform, what do we have in the Linux world that compares? Is it the kernel? Certainly not, because Android and ChromeOS both use the Linux kernel, and I don’t know anyone who would call them part of “our platform,” whatever that may be. Is it systemd? Many distros don’t use it, and as much as it’s derided for bloat, it doesn’t provide nearly everything a platform needs to provide. freedesktop.org? It includes a lot of API standards, but again, not all the libraries needed to build an app.

So maybe the platform is your DE? Or a combination of these things?

There is something in the Linux world that is unmistakably a platform: elementaryOS. It has its own libraries and its own system services. It has APIs, a HIG, and a community of users who have expectations for how their apps work. Even though many of elementaryOS’s components are third-party–like the kernel, low-level software, flatpak, and GTK–they’re still packaged and officially endorsed by elementary as part of the platform.

Developers like platforms. Having a somewhat predictable environment allows us to focus our limited time on writing the meat of our apps, not debugging arcane “works on my machine” errors. Users like platforms, too: consistency is key to user-friendly UX, and we all love to deride Windows and its half-dozen design languages. For less technical users, it gives a concrete identity to their computer system that they can learn and reason about.

In light of all this, GNOME developers want to move away from being “just” a desktop environment, one interchangeable component of a super-modular system. We want GNOME to become a mature, cohesive, defined platform that developers can target and users can learn.

Humans generally hate change. We are all too often unable to lay down what’s good to find what’s best. So I’m not at all surprised that many people (including, maybe, you) are hesitant or hostile to these changes. Maybe your concerns are well-founded, which is good: that means they can be addressed!

The main concern I see, and a very valid one (but, I hope to show, misplaced), is that we’re fragmenting our already tiny market share.

The Problem of Fragmentation

If we all spend our resources on different platforms, it means less for everyone, is the reasoning. Wouldn’t it be wiser if we all collaborated on one Linux platform? We could spend all our collective effort making one project the best it could be! There are several problems with this. Most obviously, good luck getting everyone to work together! We have different goals, plans, and resources that are not always better served by working together.

But the premise is flawed in the first place: “If we all spend our resources on different platforms, it means less for everyone.” This is not necessarily true, even if the dominant proprietary platforms would have you believe it.

Meaningful compatibility is anathema to proprietary platforms. It’s a bulldozer to the garden walls that they so carefully set up around their ecosystems. Sure, there’s a few shared components and some standards for important or low-level stuff, but nothing core to the user experience. Nothing that would be easy enough to swap out for, gasp, their competitor.

I’m not surprised that people think “different platforms” == “incompatible”. It’s so well ingrained in tech culture that, it seems, even us Free Software folks sometimes think it. We had better not fall for that trap. What Microsoft, Apple, and Google consider a weakness is Free Software’s greatest strength.

The Solution of Compatibility

Collaboration is central in the history of Linux and Free Software; in fact, I’d go so far as to say it’s the fundamental strength of our way of producing software. From the very beginning, it’s been about sharing code and inviting everyone to participate in the development process.

Collaboration has a huge impact on the resulting software. Because the different Linux platforms collaborate on standards, apps written for one platform usually work just fine on another. Imagine if Microsoft pre-installed Apple’s Mac App Store on Windows, and all the apps worked right out of the box! How preposterous! But that’s exactly what we have on Linux, and it’s not going anywhere, no matter how many new platforms we invent.

In fact, cross-platform compatibility is only getting better, and if I may be so bold, I think the clear distinction between platforms is driving these improvements. For example, Flatpak, love it or hate it, is an easy way to install any app on any platform. It works because we have a notion of a “platform” and because Flatpak runs an app in its native platform runtime, rather than the system’s native platform. Because apps don’t have to juggle a dozen different platforms, they can excel at just one.

Sure, the app may no longer look “native,” but is that really a priority? It won’t act native anyway–platforms have deeply embedded design patterns and expectations, and fulfilling them all would amount to writing a separate app. I think it’s okay for GNOME apps to look like GNOME apps and for KDE apps to look like KDE apps. By letting apps use their own platform, we’re sacrificing surface-level consistency for a deeper and more meaningful compatibility.

Of course, compatibility only works when we can agree on things.

We Have Standards!

The only reason an elementaryOS app can run on GNOME unmodified is the freedesktop.org standards. This is where the major platforms agree on how apps should be able to list themselves in the launcher; open a native file chooser; show a notification; and a very long list of other important things.

Recently, the list grew a little bit: support for a global dark mode preference was added. elementaryOS and GNOME both support or will soon support it, and the possibility is there for other desktops to do so as well. One switch will work reliably for apps across any standards-compliant platform. This is a great example of collaboration, and hopefully we’ll see much more of it in the future.

By relying on these APIs, apps don’t have to care what the underlying platform is. They only have to care that it complies with standards. This is the great simplifying power of standardization: Many apps, many platforms, one standard in between. And those “many apps” and “many platforms” bring me to my final point, and it’s about every Linux power user’s favorite word: choice.

Sources of Choice

Some choices are meaningful and some are not. Technically, I have a choice whether I want to go to school every day. The consequence if I don’t is that I probably fail and lose my scholarship, so it’s not really a choice. The same is true with technology. A macOS user could choose to switch to Windows if they thought it suited them better, but that would involve finding new software to replace the Mac-only apps they used to use and converting all their files to the new formats. It can be done, but it’s in Apple’s best interest that you never feel like it’s worth the effort.

Such “technically choices” are completely meaningless. In the Linux world, we want to offer people real choices, and that doesn’t always mean configuring and theming and tweaking every detail. Sometimes it does. Sometimes it means not doing that. It depends on the person. And we offer that choice, too: the choice of which Linux platform you use in the first place.

But unlike proprietary platforms, when we offer that choice, it’s a meaningful one. You can switch with minimal disruption. All your apps will still be there and all your file formats will still be recognized. We aren’t trying to build a wall around our garden, but offer you different paths through it.

The truth is, Linux is already split among many diverse platforms. The sooner we accept this truth, the sooner we can carry it to its full potential.