In the open-source world, we’re quite familiar with projects. Write some code to solve a problem, make sure it works for you, maybe put it in a Git repo, and voila! A project is mostly personal; you scratch an itch and improve your life a bit. It’s how everything starts.

Then you put your Git repo online to share your project with others, and it begins to transform into a product. A product is outward-focused; its purpose is to be of value to others. To succeed, it must grow organizational components such as defined scopes of features and support, documentation, promotion and advertising, methods of distribution and updating, formalized feedback channels, decision-making processes, and so on.

This transition is hard, and it can burn out FOSS maintainers of productized projects who suddenly find themselves corresponding with rude strangers without pay and lacking the time to focus on the parts of the project they found fun. It takes a very special and rare kind of volunteer to consistently do this work for free.

In the commercial world, product development and maintenance is sustained by the money people pay to buy the product. But in the FOSS world, we’re in this awkward valley where our products are frequently competitive in functionality and reach with the commercial ones, but we don’t generally charge money or benefit from a funding stream to keep them going sustainably.

FOSS funding

…But sometimes we do! For example, the Krita foundation pays several engineers to work on the product. KDE e.V. now also pays multiple people to do critical technical work for Plasma and its surrounding app and library ecosystem: porting and platform maintenance, writing and maintaining customer-focused features, documentation, and packaging. This isn’t cheap! And because we give our products away for free, the money to pay the people consistently doing this important work is very limited and comes from corporate patronship, individual donations, grants, and sometimes paid downloads on the proprietary app stores. Keeping this financial flow going is itself a lot of work! This is normally the part where I beg you to donate! 🙂 But not right now. Right now I want to explore alternatives.

Software is hard to sell. Always has been. These days the most successful funding models for software are not a great match for what we typically build, and some even seem sort of fundamentally icky or morally objectionable, like DRM-restricted subscription services, micro-transactions, or being ad-supported. Software sold with these models is exploitative, so that’s no good. And the older model of paying for download makes even less sense for us since the source code of our products is available for free and there’s already an enormous surrounding infrastructure for the packaging and distribution of open source software. Why would anyone pay to download something they can get for free legally and almost effortlessly?

To get people to pay for a product or service, you have to provide something they can’t already easily and legally get themselves for free.

Like hardware devices

This is why I think it’s so important that we have hardware vendor partners: hardware devices are inherently products that people pay for. When KDE’s hardware vendor partners use KDE’s software in their products, it pushes that software more in the direction of being product-friendly–which is to say, user-friendly. Some of our vendor partners even pay people to work on improving KDE software directly, which is amazing and it’s something I’d like to see even more of. There are also financial benefits for KDE e.V. in the form of patronship dues and getting a portion of sales, which can be re-invested to pay for work on the software in general; I think it’s important that a majority of technical decision-making remains in KDE.

But if the product is the laptop or phone or gaming console, what does that make Plasma?

A toolkit for building products

My KDE colleague Niccolò Venerandi published an interesting video about this the other day (and also here in text/blog form). Basically he echoes an Akademy 2022 talk given by KDE e.V. president Aleix Pol Gonzalez about how Plasma itself is a kind of toolkit for building the software UX for products. I’ve also written about this before.

In this way of looking at it, the Plasma Desktop we’re all familiar with is one such UX built by KDE itself, and companies like Valve, Slimbook, Kubuntu Focus, Tuxedo, and Pine64 ship Plasma-powered products using that desktop UX and others. We even learned at least year’s Akademy that Mercedes is driving their in-car UI with KWin, Plasma’s window manager!

Now, this doesn’t mean you should go all “well akshually…” on your friends when they say “Plasma” or “KDE” to mean “Plasma Desktop.” Who cares! It’s obvious. And the Plasma Desktop is probably going to be our biggest thing for a while. It’s got the longest history and the most passion behind it. But the point stands: beneath Plasma Desktop lies a whole flexible system for quickly building other UX paradigms better suited for different kinds of devices.

If you don’t use that capability in your daily life, that’s fine. If you do use it to transform your Plasma Desktop into something totally unique that’s perfectly adapted to your personal needs and desires, that’s fine too! And what’s even more fine is when companies use this functionality to sell products with a Plasma-powered UX and invest in KDE! Seen in this way, Plasma is a powerful tool for all kinds of embedded software-driven products. We’ve already done most of the R&D that you’ll get for free; it just makes sense.

Being product-friendly

If Plasma is a tool to reduce cost and risk when building a product that uses it, we need to treat it more like what it is: a B2B developer tool. This means things like focusing on distro and hardware vendor use cases; ensuring painless and bulletproof customizability; maintaining documentation for all features; providing a rich library of components; offering a friendly and adequate out-of-the-box UX; having our own distribution and updating tools you can use if you want; and pitching our work to potential customers. Do all of those things sound familiar? They should! It’s what many members of the KDE community have been focusing on over multiple years. Documentation in particular is sorely needed to improve adoption by product-focused companies, and that’s why KDE e.V. hired a documentation contractor early this year. And KDE e.V. has a marketing team too, to improve outreach! Hmm, almost sounds like there’s a plan in place!

How to help

If being part of a movement to help get a Plasma-powered UX on all sorts of devices sounds cool and exciting, there a lot of ways to help!

• Keep using Plasma Desktop, submitting bug reports, and fixing stuff; keep being awesome! Focus in particular on hardware integration and developer UX.
• Help write developer documentation, particularly around shell customization and theming.
• Be aware of the larger context and understand how proposed changes will affect others who use Plasma and Plasma-powered products. We don’t exist in a vacuum! The project is larger than us.
• If the company you work for is using Plasma on their devices, start a conversation internally about becoming a KDE Patron, or about devoting engineering efforts towards direct upstream contributions to Plasma.
• If the company you work for isn’t using Plasma on their devices, pitch it to them!
• Donate to KDE e.V. so we can hire more people to technical work and offer expanded hours and work opportunities to the people we already have (they are currently part-time or less).

You might be aware of the recent Linus Tech Tips videos about switching to Linux, including one with some complaints about KDE software. For those of you who are following along, I want to let you know that we’re working on fixing the issues Linus brought up, and you can track our progress here. Thankfully most of the issues are fairly minor and should be easy to fix.

This blog post is my version of Sway developer Drew DeVault’s post about the videos, regarding the question of what desktop Linux needs to go mainstream. Drew emphasizes accessibility, and I agree, but with a slightly different conclusion:

Desktop Linux needs to be pre-installed on retail hardware to succeed in the mainstream.

That’s it.

Allow me to explain.

People get hung up a lot on features and usability, and these are important. But they’re means to an end and not good enough ends by themselves. Quality means nothing if people can’t get it. And people can’t get it without accessible distribution. High quality Linux distros aren’t enough; they need to be pre-installed on hardware products you can buy in mainstream retail stores! “The mainstream” buys products they can touch and hold; if you can’t find it in a mainstream store, it doesn’t exist.

Think about it: why do normal people use Windows or macOS? Because the physical computer they bought included it. iOS or Android? Because it was shipped by default on their physical smartphone. The notion of replacing a device’s operating system with a new one doesn’t exist to “the mainstream”. Only the “three-dot” users ever do that, and they’re about 5% of the market. If the only way to get your OS is to install it yourself, you have no chance of succeeding in the mainstream.

As for features, people generally use only a very small fraction of what’s available to them. When it comes to usability, most users memorize their software rather than understanding it–and you can memorize anything if you really have to. A better user interface helps, but it isn’t needed for the memorizers and mostly benefits power users (the 30% of the market “two-dot and up” crowd) who recognize patterns and appreciate logic, consistency, and good design. So these are not good enough on their own.

This doesn’t mean we should forget about features and usability! Not at all! But if the goal is to “go mainstream,”we have to understand the true audience: hardware vendors, not end users. The goal is to have a software product appealing enough to get picked up by vendors when they go shopping for one, because that’s mostly how it works. Companies like Apple that do their own custom top-to-bottom hardware and software for big-name products are rare. Most build on top of 3rd-party software that requires the least integration and custom work from their in-house software team. If your software isn’t up to the task, they move onto the next option. So when some hardware vendor has a need, your software better be ready!

And what do hardware vendors need?

• Flexibility. Your software has to be easily adaptable to whatever kind of device they have without tons of custom engineering they’ll be on the hook for supporting over the product’s lifecycle.
• Features that make their devices look good. Support for its physical hardware characteristics, good performance, a pleasant-looking user interface… reasons for people to buy it, basically.
• Stability. Can’t crash and dump users at a command line terminal prompt. Has to actually work. Can’t feel like a hobbyist science fair project.
• Usability that’s to be good enough to minimize support costs. When something goes wrong, “the mainstream” contacts their hardware vendor. Usability needs to be good enough so that this happens as infrequently as possible.

It doesn’t need to be perfect. It just needs to do that stuff. This is how Windows conquered the PC market in the 90s despite being terrible! And our stuff is much better!

I see evidence that this is already working for KDE. Pine ships Manjaro with Plasma Mobile and Plasma Desktop on the PinePhone and PineBook Pro, respectively. Valve also picked Plasma Desktop for the Steam Deck, replacing GNOME for their new version of SteamOS. I see KDE software as well-positioned here and getting better all the time. So let’s keep doubling down on delivering what hardware vendors need to sell their awesome products.