Category: FOSS culture

Legal obligations vs social contracts

My post about responsibility for bug reports on old software versions the other day stirred up quite some discussion, and I wanted to drill a bit more into what I think is the crux of the dispute: the difference between legal obligations and the social contract.

When you package and distribute free open source software (FOSS), you legally have to comply with the terms of the license: “make the source code available,” “don’t change the license,” and so on.

You might also notice the absence of a warranty, or silence about responsibility for bug reports.

So let’s return to the question:

Who’s responsible for bug reports on old software versions?

An accurate legal reading is “Nobody, unless you’ve signed a work contract with a developer or purchased a commercially-sold OS.” But it’s also not the whole picture, because there’s another potential non-obvious legal obligation:

Trademark

Trademark law varies across the world, but at least where I live in the USA, “unregistered trademarks” are a thing, and in a professional context, you’ve got a legal obligation not to violate a product’s trademark — registered or unregistered — by referring to it as something that it isn’t, or changing it and saying it’s still what it originally was.

Ah, but how much to you have to change it before that kicks in? That’s definitely not something that I — a non-lawyer — am qualified to assess. And my understanding is that this varies a lot across the world’s legal regimes, too.

But my layman non-lawyer perception is that applying bug fixes (especially backports of the developer’s own bug fixes) probably doesn’t count, while making visual or functional changes not from the developer probably does press closer to that fuzzy line.

Which brings me to what I think is the most important part:

Doing only the legal minimum

“Follow the terms of the license agreement.” “Don’t mis-represent trademarks you don’t control.” “Don’t steal.” “Don’t murder.”

These are good places to start. But what if that’s all anyone ever did — the bare legal minimum?

I think the world would be a pretty miserable place. There’s no law requiring anyone to love you or soothe your feelings when you’re upset. There’s no law requiring you to find a source of joy or direction in life, or help others unbidden.

What makes life worth living is everything beyond the legal minimum: politeness, kindness, friends, love, pleasure, purpose, art, music, entertainment, faithfulness, professionalism, and so on.

Everything desirable but not required by law comprises the social contract: a set of unwritten rules that, the more people follow them, the better their society is to live in. It helps personally, too: follow the social contract, and you’ll end up calmer and happier, be perceived more positively, and things will just kind of start going your way, as if by magic. Break it, and the opposite starts to happen.

Applying the social contract to this situation

Let’s say that I write an app, and someone distributes it with a feature patched in that I didn’t write, or a visual change that I didn’t make. How mad at them am I going to be?

If we have a bad relationship due to previous perceived violations of the FOSS social contract, I might be very mad. I might complain publicly, or even threaten to enforce my trademark and demand they change the branding to reflect the fact that they’ve created what I believe to be a derivative work that reflects poorly on the original.

No matter what, we can be sure it will escalate into a fight with a winner and a loser. And that loser might be me.

But if we have a good relationship and view each other as pro-social upholders of the FOSS social contract? I might be really happy about this, or at least tolerate it. Maybe I’ll even reach out and ask them to submit their change upstream and help maintain it. There’s a 0% chance I’m going to threaten to invoke trademark law or give them a hard time about it.

That’s the power of respecting the social contract that exists between us.

But what is the FOSS social contract?

Like the definition of “derivative work”, it’s unsatisfyingly fuzzy and nebulous. But like a cloud, even if we can’t contain 100% of it in a jar, we can probably identify many of its features. So here are some pro-social behaviors that I hope we can all agree are squarely within the “FOSS social contract”:

Using FOSS

  • If you didn’t pay any money, appreciate what you’ve gotten for free. It’s a modern miracle.
  • Understand the basic software lifecycle of the OS you’re using, and choose the one that suits your needs the best.
  • Accept the “no warranty” clause. Understand that support may be slow, and that if you need it fast, you’ll need to pay for it.
  • If you don’t like the software you’re using, use something else.

Bug reporting

  • Endeavor to report bugs in the right place, to the best of your ability.
  • Phrase your bug reports gently, and articulate a real problem to be solved, rather than making demands or suggesting solutions.
  • Be understanding of the fact that your request might be a big ask that might not get done soon, or might be better done in a different place or in a different way.
  • Treat people kindly with the benefit of the doubt, even if they don’t respond to your bug report in a timely manner, or at all.
  • If your needs are urgent, pay a person or company to address them; don’t make demands of people working for free.

Software development

  • Do your best to respond to polite and helpful bug reports in a timely manner. Read your email. Don’t ghost people.
  • If you aren’t distributing your own software in a way that’s suitable for 100% of your users, appreciate the free efforts of distributors who are doing it for you, even if they aren’t doing it in exactly the way you would prefer.
  • Work with your distributors to help them showcase your software in the best light. They don’t know it as well as you do.
  • Don’t piss off too many of your users. You’re doing this for them, not just for yourself.
  • Only make your software publicly available via a FOSS license if you’re willing to accept people using it or distributing it in ways you might not have expected or preferred.

Software distribution

  • Do your best to respond to polite and helpful bug reports in a timely manner. Read your email. Don’t ghost people.
  • Respect the reasonable wishes of the developers whose software you distribute. Keep up good relationships with them as much as possible.
  • Clearly communicate your OS’s software lifecycle and release schedule. Curate your users so everyone using your OS is within its intended audience.
  • If you meaningfully change the software you distribute (outside of backporting the developers’ own bug fixes or similar), accept that you’ve created a derivative work that needs to be presented accordingly: At the minimum, change the name, icon, and metadata (like the bug report URL).
  • If you distribute software that you know is or soon will be outside of its developers’ support window, change the bug report URL to your own, or remove it entirely if you don’t have the resources to offer support for old software.
  • Only create an OS in the first place if you’re willing to take responsibility for the support needs of the people who will use and depend on it.

Hopefully we can all agree that if everyone considered the above ideas to be part of the social contract they follow, our world would be a very friendly and pleasant place! We’d end up with way fewer arguments and disputes, and could more and more get on with doing the fun part of what we do. And it’s my hope that we can all aspire towards these ideal with our actions and words.

Who’s responsible for bug reports on old software versions?

Consider this hypothetical:

An operating system (OS) ships version 1.5 of a piece of software.

Meanwhile, the latest version of that software is 3.0.

A user on that OS experiences an issue in version 1.5, or has an idea for a new feature. Who should they contact?

This hypothetical becomes concrete due to the existence of discrete-release OSs, like Ubuntu, Debian, openSUSE Leap, and Linux Mint. These intentionally freeze on certain versions of the software they ship for a certain period of time — even if newer versions have already been released upstream of them.

It’s in the news right now because of a recent kerfuffle over in Linux Mint specifically; a developer of GNOME Calendar asked Linux Mint to patch out support links and change the branding, and later followed up with a fairly inflammatory blog post after the issue was locked for understandable reasons.

This saddens me because the miscommunication was preventable, and now a good portion of the discussion surrounding the topic is about tone rather than the topic itself — a predictable outcome of not caring about tone. But I digress.

I think it’s an important topic, so I thought I’d share my take on the situation.

Are software developers responsible?

Software devs wrote the software. The software broke. End of story.

If only life were that simple!

Having been on the receiving end of thousands of un-actionable bug reports about old versions of KDE’s software in discrete-release OSs for issues that were fixed months or years ago (but not backported by the OS distributor!)… I can tell you it’s very frustrating.

But we in the free, open-source software (FOSS) world make our software available via free software licenses; we need to be prepared for OSs distributing our software in ways we didn’t anticipate or aren’t thrilled about, and bug reports from their users. That’s life.

Our solution in KDE is a bot that automatically closes bug reports for versions of Plasma that are out of support, and we may eventually broaden the system to cover our apps and frameworks, too.

It’s not perfect, but it mostly works out. I can tell because most of the new Plasma bug reports I see these days are from users of rolling-release OSs like Arch, OpenSUSE Tumbleweed, and Fedora KDE (which is not truly rolling, but it’s close enough), and I’d say most are actionable.

It kind of stinks for users of discrete-release OSs, who get a robot telling them that the work they just put in to report the bug was useless. But they also benefit from rolling-release users effectively being their free quality assurance (QA). Trade-offs.

Are distributors responsible?

If my car breaks, I blame the car company — not the vendor who sold them the part that broke.

(well, maybe I blame them too if I’m a car nerd, but that’s the exception!)

Ultimately OS distributors are the car company here, assembling the final product. It’s their job to do adequate QA and work with their vendors (upstream software devs) to make sure that final product sparkles.

Of course, a new car costs many months’ salary and includes a multi-year warranty, while most FOSS OSs don’t and are distributed for free. So expectations need to be tempered a bit.

This is where I think communication breaks down. A lot of free-of-charge FOSS OSs advertise themselves really positively, promising the sun, the moon, and the stars. Whereas the truth for many is that they’re assembled by a small team with a shoestring budget (or none at all) from years-old software offered by grumpy developers they don’t have a great relationship with.

Users then don’t understand the full picture of who’s responsible for what, or the level of support they should expect and from whom.

This is the reason why KDE Linux includes tons of qualifiers and provisos in its marketing material. We don’t want to over-promise! It’s a small project built by a small team. I think every piece of free software should be clear about who should use it… and who shouldn’t. Don’t over-promise! It’s a recipe for frustration and disappointment on all sides.

And if you want an OS with professional backing, you’ll likely need to pay for it.

So what’s the solution?

As a distributor, I think you need to sort out what kind of relationship you want to have with the developers of the upstream software you ship.

Do you want to be able to have a distant relationship? Then I recommend abandoning discrete releases and adopting the rolling release approach.

In this model, you take upstream software the moment it’s released — or at least soon afterwards. Then the conflict disappears! Almost all bugs become upstream bugs, and you can direct users to upstream devs without getting any push-back from them. Everything remaining is an issue that you can fix in your OS.

Rolling release OSs can still have good relationships with their upstreams, of course. But it isn’t as critical.

Don’t want to be a rolling release? That’s fine. Then you need to work closely with your upstreams.

Communicate your users’ complaints and bugs upstream, help drive fixes, and then ship them. Many software developers already release bug-fix versions in addition to feature versions. If they do… ship them! Don’t ignore them; this will make your upstreams grumpier.

If any of your upstreams release a “long-term support” version of their software, ship that. If they don’t, you can even work with them to create one if they’re amenable to the idea, and help to support it.

This is more work, obviously. So if your team is small, it may not be feasible to do for every piece of software you ship. But you can try for the most important ones: the Linux kernel, systemd, Mesa, Libinput, PipeWire, NetworkManager, BlueZ, udisks, CUPS, and KDE or GNOME.

But that’s the important point: shipping a high-quality discrete release OS is more work than producing a competent rolling release. No way around it.

So a way to make this approach more feasible is to reduce your OS’s scope of concern.

For example, you can delegate app distribution to a third party like Flathub, the Snap store, AppImageHub, etc. This lets you focus on just the base OS and its desktop environment, while apps are rolling, which means they’ll accept bug reports about them. Personally, I think there’s a lot to like about this model.

It also helps if you don’t let the software get too out of date. Up to 6 months old? Your upstreams are likely fine with this, and will accept bug reports. 12 months? Mostly fine. 2 years? That starts to get painful for your upstream developers if users are still reporting bugs to them. 3 year or more? Very painful. We pretty much have to direct them to their OS vendor.

What’s not the solution?

Package 2+ year-old frozen releases of as much upstream software as you can, and then ignore the upstreams, their bug-fix releases, and their complaints about this.

This is the worst of all worlds!

  • Users get outdated software that’s full of bugs and security holes fixed long ago
  • Software developers get un-actionable bug reports from angry and confused users
  • Distributors get frustrated communications from software developers that damage or destroy important relationships

Please don’t do this. It isn’t sustainable over time, and will cause a leak of the most desirable users who make an active choice to use your OS.

How do I know this?

Well, I don’t, but I can make an educated guess based on some of the few statistics we do have. A big one is the OS market share on ProtonDB as compiled by BoilingSteam, which counts Linux gamers:

In 2019, the “rolling and rolling-ish (e.g. Fedora)” OSs made up a little over 36% of the total users.

In 2026, they’re up to 71%.

This isn’t everyone, of course; only gamers using ProtonDB. But still, it’s quite a change. Clearly gamers believe rolling-release OSs cater to their needs better than discrete-release OSs do.

So, if you ship a discrete release OS, and you don’t want to or can’t switch it to a rolling or semi-rolling release cadence, please please please work with your upstreams! As a (sadly now only merely occasional) upstream KDE software dev, I can tell you my favorite distributors to work with are the ones who engage with KDE and help get problems solved. It’s a lot of fun when all parties focus on problem-solving.

“Long-Term Support” doesn’t mean what you think

My last post about good beginner-friendly KDE-focused operating systems sparked some discussions about the concept of “Long-Term Support” (LTS) releases.

But what does this term mean? It’s a bit generic-sounding, making it easy to interpret as meaning almost anything. So let’s go to the source: how the term is defined by the operating systems using it! Here are the non-commercial ones:

Debian Stable says:

Security updates are provided by Debian security team for three years. This generally means that each stable release is supported for its whole life plus an extra year (or so) after a new version of stable is released. In addition, further security support is provided by the LTS and LTS/Extended projects.

Ubuntu says:

LTS stands for long-term support — which means five years of free security and maintenance updates

Kubuntu says:

The latest Long Term Support (LTS) version of the Kubuntu operating system for desktop PCs and laptops, Kubuntu 26.04 [is] supported with security and maintenance updates, until April 2029.

(I didn’t include openSUSE Leap because its marketing material doesn’t use this term, though what it offers is fairly similar in practice)

So these operating systems are fairly consistent about what “Long-Term Support” means to them:

  • Each discrete OS release will continue receiving updates for a certain number of years.
  • Those updates will include fixes for security issues.
  • Those updates may include whatever “maintenance” means; Ubuntu & Kubuntu promise this, Debian doesn’t say.
  • Those updates will not include any new features, UI improvements, or other non-bug-fix releases from the software’s developers. That is to say, each piece of software is effectively locked to a specific version for the life of the release.

That’s it! So let’s look at what’s NOT promised:

  • Lack of bugs
  • Lack of crashes
  • Fixes for non-security issues
  • Personal support for issues you encounter
  • Support for newer hardware devices (Ubuntu offers “hardware enablement” kernels for desktop installs by default, but they come with no stated guarantees and don’t cover the parts of hardware support that go beyond the kernel)

That doesn’t mean an LTS release of Debian, Ubuntu, or Kubuntu will be devoid of these things. It just means they aren’t promised. Probably you’ll get a lot of them anyway, but there’s no guarantee.

I think this is where some of the persistent confusion around the LTS topic comes from.

LTS releases are fairly reliable as long as you use the most popular software from their included software repositories. So in the circumstances when this stops being the case, I think sometimes people can feel betrayed. They think, “I thought this was supposed to be stable! Why didn’t anyone fix this bug yet? Where’s my long-term support?”

But Debian, Ubuntu, and Kubuntu never promised any level of reliability or absence of bugs. They promised that the version-locked software in their repos would receive security fixes for a certain number of years. Ubuntu and Kubuntu also offered a certain amount of non-guaranteed best-effort hardware compatibility improvements and non-security bug fixes.

That’s it!

So it’s important to understand what you’re actually getting with an LTS-style OS. And maybe it’s not for you. There are plenty of other options for people with different desires:

I want newer software

If you’re a software developer or a technology enthusiast, you may want to get software on or closer to its developers’ release schedules. This will give you a stream of new features, UI improvements, and fixes for bugs. In this case, the better option is a rapidly-updating OS like Arch Linux, openSUSE Tumbleweed, Fedora KDE, or one of their children.

The trade-off here is that you may have to live with some things that are currently working getting broken after updating. In other words, the bugs are unstable, unlike in an LTS OS where the bugs are stable.

I personally fall into this group, which is why I use a rapidly-updating OS and not an LTS OS.

I want fewer bugs

I think a lot of people choose an LTS OS to experience fewer bugs, but this is generally not a strength of the LTS product. When an LTS OS freezes on a specific set of software, all the bugs in those versions of the software are frozen, too. Unless the LTS OS provider fixes any of those bugs themselves or backports fixes for them, users will be exposed to them for the lifetime of the release.

With a rapidly-updating OS, when software developers fix bugs in their software, you’ll get those bug-fixes quickly. As long as the software itself is becoming less buggy over time, a rapidly-updating OS shipping software close to its developers’ release schedules will likewise become less buggy over time.

It’s not all puppies and rainbows, though. A fast pace of change means more opportunities for those developers to accidentally introduce new bugs, and also for the introduction of integration issues: bugs caused by software being mis-configured or incompatible with other software. LTS OSs excel at minimizing integration issues between software, because a frozen set of software isn’t a moving target for QA testing.

So in a lot of ways, this choice boils down to whether you’re more bothered by software bugs or by integration issues.

I want better hardware support

If the manufacturer of your device didn’t provide much or any Linux software support for it, a rapidly-updating OS is likewise a better option here. You’ll quickly get all the components that improve hardware support, not just the parts in the kernel.

I want a true reliability guarantee

If time is money for you, this makes sense. And to get it, you’ll need to pay for a commercially-supported operating system. For example, Canonical offers “Ubuntu Pro” with a level of support that includes the following:

Build with confidence with 24/7/365 phone and ticket support. Get prompt help when something breaks on any of the packages in the Ubuntu Main and Universe repositories, including the most widely used open source applications and toolchains. Our 24/7 plans now include SLAs not only for initial response times, but also for ongoing follow-up updates ensuring continuous visibility and faster remediation throughout the lifecycle of your support case.

Wow! Now that’s support. It costs $300 per year for workstations (servers are over 5x as much).

Red Hat and SUSE offer similar services at similar prices.

And they aren’t cheap! But if time is money, those prices may look pretty reasonable. And you’ll get to talk to a perky and friendly person over the phone when you encounter a covered problem, and someone will to take direct responsibility for getting a fix delivered.

What about Flatpak and Snap?

In principle, these technologies allow an LTS-style OS to offer the best of both worlds: a stable base with apps updating more rapidly.

In practice, what you get is a mixing of both worlds. The base OS retains its LTS characteristics, while apps become rapidly-updating, giving you some exposure to breakage coming from new versions alongside more features, UI improvements, and fixes for existing bugs.

We’re spoiled for choice in our ecosystem, which means everyone can find a free software operating system that matches their needs and desires. But you have to know what those needs and desires are, and also successfully map them to the available options! Hopefully this blog post has helped explain what the LTS-style operating systems offer, and who should use them.

While you support others, who supports you?

The world of free and open-source software (FOSS) is full of big-hearted, altruistic people who love serving society by giving away their labor for free. It’s incredible. These folks are supporting so many people by providing the world with high quality free software, including in KDE, my FOSS community of choice.

But while they do it, who’s supporting them? We don’t talk about this as much.

A recent Reddit post by a volunteer developer burning out reminded me of the topic, and it’s not the first one. Denis Pushkarev of core-js wrote something similar in 2023, and we’re probably all familiar with this XKCD comic:

The topic is also not limited to the FOSS world; it’s broadly applicable to all volunteer activities. Can’t feed the homeless in a soup kitchen if you’re sick and sneezing into the soup! Can’t drive to the library to teach adult reading classes if your car’s broken down.

In order to support others, you need support yourself! Who can provide that support? Here are a bunch of cases that work:

  • Yourself in the present (with a job — related or unrelated to your FOSS work)
  • Yourself in the past (retired)
  • Your partner in the present (married to a primary or sole income-earner)
  • Your partner in the past (partner left you lots of money after death or divorce)
  • Your parents in the present (you’re their dependent)
  • Your parents in the past (born rich or received a big inheritance later)
  • The state (disabled, a student, or on a similar program)

All these cases work. They provide enough money to live, and you still get to work on FOSS!

There are lots of other good options, but here are some of the bad ones that don’t work:

  • Other people via donations: you never get enough donations, and if you put the effort into fundraising required to make it work, that becomes your job.
  • Yourself in the future: if you’re living off loans, you’re screwing over future you!
  • Nobody: if you’re eating up your savings, you’ll eventually run out of money and be destitute. If you’re fortunate enough to live in a place where “The state” is an option, it will be at a diminished standard of living.

We must always answer for ourselves the question of how we’re going to be supported while we continue to contribute to the digital commons. If you don’t do it for a living, it’s a critically important question. Never let anyone guilt-trip you into doing volunteer work you don’t have the time or money for! It’s a sure road to burnout or worse.

Airplane safety briefings tell people to “put on your mask before helping others.” Why? Same reason as what we’re talking about here: you can’t support others if you’re not first supported yourself. If you try, you’ll fail, either immediately, or eventually. You must be properly supported yourself before you can be of use to others.

Tools that Just Work™ …until they don’t

As a former Apple guy, it pains me a bit to say this, but I’m coming to believe that the whole “It Just Works” thing is a temporary illusion.

Oh, it can be achieved! But the real trick lies in keeping it. This came to mind while I was watching a video about one of Bambu Labs’ very impressive-looking Apple-style “It Just Works” 3D printers, and felt myself drawing a parallel between the world of 3D printing and our more familiar KDE world.

As I mentioned recently, my first real introduction to the world of free software was 15 years ago with 3D printers, back when the field was dominated by RepRap hackers designing open hardware and software. And last year, I bought a new printer for the first time in over a decade. After drooling over a bunch of very cool Vorons, I eventually settled on a Prusa Mk4 instead of a different Bambu printer that looked very impressive at the time: printing faster, having an enclosed chamber and smoother wireless functionality, being cheaper, and looking prettier.

But the Prusa felt like KDE: simple by default, but powerful when needed. Big friendly community. Built by a company led by one of the early RepRap hardware hackers. Buying it was investing in the people helping to keep their part of the industry open, rather than private. No spyware, no lock-in, no phone app or internet connection needed. Can’t be bricked if the company goes out of business. Open, hackable, humane, trustworthy.

I’m making this sound like the decision was some sort of ideological compromise, but the Prusa Mk4 is also excellent. It’s as good or better in many ways, almost as much in others, and its UX still pretty polished. Maybe it’s not Apple polished, but it’s very easy to use and produces great prints. I did have to invest a bit more time and money into the Prusa upfront, but now I have a tool I can truly rely on, not because it’s got a seamless auto-updating cloud-based AI-enabled UI, but because it doesn’t.

And since then, both companies went in exactly in the directions I expected: Prusa released a new version of their printer that’s cheaper and better, plus a $100 kit for existing owners so they don’t have to buy a whole new thing… while Bambu released a firmware upgrade that lets them control how your Bambu printer can be used.

It Just Works… until it doesn’t.

I’m glad I went with the Prusa, the same way we’re all glad we went with KDE over Apple or Microsoft. In KDE we know this well, so it’s up to us to spread the message to everyone else: resist the lure of “easier now, screwed later.” This is where the big commercial offerings start to fail: anything proprietary and closed source that Just Works may simply stop working at any time. You’ll invest in it, and it’ll work out great for a while, but then start to worsen, break, or exploit you.

Even as we invest in making our software easier to use, we need to level the playing field by advertising our advantages in ownership, privacy, personalization, and freedom. Our software is trustworthy because it can’t be taken away by us or anyone else; you’ll be able to use it over the long term, developing skills and efficiencies over time. Investing in KDE is investing in yourself, rather than someone else’s bottom line.

25 ways you can contribute to KDE

In honor of KDE’s impending 25th birthday tomorrow, here are 25 ways you can get involved to help make KDE software the best in the world!

  1. Be kind. Most KDE people are either volunteers, or paid employees who work on KDE stuff far beyond their working hours. These folks put their heart and soul into KDE, and often the most impactful thing you can do is to express appreciation to someone you see going above and beyond the call of duty. Be positive, not negative. KDE is made by people with feelings, like you!
  2. Submit code to fix bugs, implement new features, or improve the accessibility of KDE software!
  3. File a bug report for every problem you encounter! You might be surprised by how many people don’t do this, and assume that KDE’s developers are already aware of your issue. We become aware through bug reports!
  4. Help translate KDE software into your native language!
  5. Volunteer to work on sysadmin stuff. KDE’s sysadmins are always terribly overworked and in need of assistance!
  6. Subtly advocate for FOSS in general and KDE software specifically to the people in your social circle who depend on you for technical advice and support. Don’t be pushy, but make it clear you’re willing to help them migrate once they get sick of Windows, macOS, software that’s riddled with ads or tied to a paid subscription, and proprietary file formats that lock you into one app. Admit it, you’re the nerd who your friends and and family rely on! Your words have power! Use it wisely. 🙂
  7. Work on KDE’s formal promo efforts to get the word out about KDE software!
  8. Donate money to the KDE e.V. to support hiring more employees and paying for development sprints!
  9. Help maintain and expand KDE’s web presence!
  10. Design new icons to fill some of the gaps in the Breeze icon theme!
  11. Help work on the visual design of KDE software!
  12. Purchase FOSS hardware in general, and specifically, hardware with KDE Plasma preinstalled!
  13. Help a local school or small business install a Plasma distro on aging hardware so they don’t need to buy new stuff at high cost!
  14. Start contributing in your distro of choice to help them integrate KDE software better, ship a more appropriate set of default applications, update old themes which have drifted out of sync with what they were forked from, and so on!
  15. Triage bug reports to help developers focus on real issues!
  16. Answer KDE users’ user questions on social media and help people get the most out of KDE software!
  17. Review merge requests in projects you’re familiar with. This is an under-appreciated but very important way to contribute, even if you don’t consider yourself a technical expert. But you can test the changes to see if they work as described, and I bet you can also spot misspellings, obvious code errors, and weird user interfaces that could stand to be improved!
  18. Improve documentation–especially if you used the documentation and found something wanting. The best candidate to fix bad documentation is someone who just read it and found problems with it or didn’t find it as helpful as it would have been!
  19. Help manage stuff. KDE is desperately in need of “big picture people” capable of seeing things from a 10,000 foot view and helping strategically important work move towards completion!
  20. Be nice to other FOSS projects. We may be here for KDE, but GNOME is a good project too. There’s room for more than just one, and in fact healthy competition between projects is a good thing! Do don’t hate on GNOME if you’re a KDE person. They do a lot of things right and they produce quality software. Be a good ambassador!
  21. Start a local KDE user group. You might make some new friends and discover more local users of KDE software than you thought!
  22. Volunteer at your local school or university to teach students about programming or the importance of software freedom–with a KDE tilt, of course! 😉
  23. Attend Akademy, KDE’s yearly conference. Eventually it will be an in-person event again, and let me tell you, it’s a lot of fun to spend several days around members of your digital tribe!
  24. Install Plasma on as many of your home devices as possible! Experience more freedom, as well as testing more esoteric use cases. This is valuable because there is only so much hardware the core developers can test again, we rely on our users to provide reports about problems with the full diversity of what’s available out there!
  25. Don’t sweat it if things aren’t perfect–like this list of 25 things that basically ends at 24. 🙂

The FOSS honor culture

Tux with rocket launcher, taken from https://commons.wikimedia.org/wiki/File:Tux_Born_to_Frag.jpg

In the real world, anthropologists often make a distinction between Honor cultures and Law cultures:

  • Honor cultures emphasize the idea of “honor”–whose modern analogue might be “reputation”–to encourage pro-social behavior and fulfillment of contracts. You gain or lose honor/reputation based on the above, but you can also lose it when challenged by others, which necessitates often brutal and violent action to regain it. Historically, Honor cultures have often arisen in areas with little law enforcement or central authority; order is thus personally enforced.
  • Law cultures by contrast ensure order by having a broad and well-defined set of rules with a central authority that punishes rulebreaking. Everybody knows the rules, and knows that they will be punished for breaking them, often severely. In Law cultures, order is centrally enforced; people are free to trust one another and act pro-socially as much as possible because their safety is backstopped by the promise and threat of centralized consequences when rules are broken.

Honor cultures today are often considered primitive and backwards, while Law cultures are considered civilized and advanced. There’s a pretty logical reason for this: real-world Honor cultures have tended to evolve brutal and violent methods of regaining lost honor, including dueling, kidnapping, forced marriage, “honor killings”, and family blood feuds. The ordinariness of brutality in Honor cultures tends to push away the gentle and intellectual when migration opportunities exist, so they are weak and poor in a world where power and wealth come from knowledge. Thus Law cultures are ascendant today, and Honor cultures are on the wane… except in one notable area: the internet.

On the internet, there is no real central authority to punish rule-breakers, and there isn’t even a codified set of rules! Each website is basically someone’s private property, and personal behavior on that virtual property requires adherence to the owner’s rules. It’s up to the owners to police their domains, ensure standards of conduct, personally punish violators, maintain their own community reputation, and so on. Is this sounding familiar yet? The internet has evolved a pseudo Honor culture to maintain a semblance of order!

And FOSS communities, being largely digital in nature, follow suit. Though we do occasionally meet up in person, within the physical boundaries of Law cultures (or at least we will again once the global pandemic is over), most FOSS interactions happen online, where the tenets of Honor culture are more applicable.

Now, there’s one major difference between internet Honor culture and physical Honor culture: you can’t kidnap or murder someone over the internet, so regaining your lost honor or repairing an impugned reputation has to be non-violent! It doesn’t have to be pleasant–a jerk may deploy an invective-filled rant, a troll campaign, or a denial-of-service attack–but it can’t physically harm or kill anyone. This removes the most objectionable aspect of traditional, real-world Honor cultures.

It’s worth noting that in the FOSS world, our competitors are closed-source software corporations, which generally operate physically and according to the rules of Law culture: “perform this task or get punished”; “obey the hierarchy to ensure your career path”; “here is your financial bonus for good performance”; and so on. And like real-world Honor vs Law cultures, the FOSS world tends unfortunately to be weaker and poorer than the closed-source one. Earning a living doing FOSS development is a common struggle. And our market share is much lower even though our output is generally better, and always more trustworthy over the long term. Overall, our internet Honor culture causes us to fit less well into the rest of the Law-culture world of rules, laws, financial instruments and hierarchies: corporations effortlessly partner, merge, hire, fire, invest, divest, buy, and sell using legal instruments, while in the FOSS world, these activities generally take place in the realm of the personal, and therefore happen much more slowly, if at all.

However the most successful FOSS projects are supported by Law-culture institutions to help bridge the gap: Firefox has the Mozilla corporation; KDE has the KDE e.V., Blender has the Blender Foundation, and so on. In the same way that a corporation existing in a democracy can be internally a dictatorship, a FOSS community in a Law culture can be internally an Honor culture. Thus internet-based FOSS Honor cultures may avoid being destroyed and retain our cultural distinctiveness and effectiveness in the face of real-world Law cultures.

I wonder if over time we will be pushed into becoming more of a Law culture to maintain and expand our competitiveness with the closed-source world, or whether our Law-culture institutions will prove a sufficient interface and allow us to remain internally an Honor culture. Food for thought, at least.

If you were hoping for a tidy conclusion, I’m afraid I have to disappoint you: this blog post is mostly a random idle musing. 🙂

(Header image taken from https://commons.wikimedia.org/wiki/File:Tux_Born_to_Frag.jpg)