In Russia, we have many typography keyboards/addons, because, well, it historically looked very silly to use double-minus or "-quotes instead of «»-quotes.

I've no idea how some countries got their typography standardized on the PCs and have it from the very beginning (Germany with their quotes for example), but the other countries need to setup external software and configuration. Apparently, US also didn't got their "third level" keyboard as a standard.

https://mfi.apple.com/account/airprint-search

https://mopria.org/certified-products

After rereading both of your websites again, I should say you've nothing wrong! It's sleepy me who accused you for nothing, sorry.

Linux printing and scanning stack is held on 5 enthusiasts basically, and is quite buggy. Any contributions welcome.

If you want to further improve your project, make it small and fast, you can compile printer filters (most of which work on cups-raster data) with emscripten. This way you don't need to use CUPS, Linux, and x86 emulation. You'll need to write some shims for CUPS libppd functions which many filters use (some don't), and either parse PPD files or convert them into another representation.

Most filters (drivers) are quite simple pipes from stdin to stdout, sometimes they don't use cups functions at all, receiving all the data directly from raster header. Some filters, such as gutenprint, are more complex and use their own backends, but even in this case it's not a hard task: libusb has emscripten WebUSB backend.

Pretty sure you have my code in both projects. I contribute first and foremost to make printers and scanners to work reliably, but also keeping in mind the idea that I could at least try to apply legal actions for companies which violate the license rules one day, as a CUPS/SANE/printer/scanner drivers contributor.

Printer companies generally don't like that: https://xcancel.com/ValdikSS/status/1745898408693371125#m

Cool project though! Hope you can publish the source one day so we can all benefit from it in the future!

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

https://github.com/cncf/foundation/blob/659fd32c86dc/dco-gui...

Imagine face recognition to work like a text chat, where the PC gets the frame from the camera and writes in the chat: "Who's that? Here's the RGB888 image in hex: ...".

This is what I'm trying to conterpoint: you're thinking of "Free software" as in legal definition of GNU (4 freedoms), and "Open Source software" as in legal definition of OSI (10 points), in terms of the licenses approved by these organizations.

Users see open-source as a combination of legal/social/community expectations, as a phenomenon. Overwhelming majority of the software have only legal license, and nothing more, and oftentimes the developer themselves don't know what their social behavior should be, they're forming it given the circumstances.

We focused ONLY on the legal definition of open source for very long, and hardly spent time on the other, IMO much more important things: for whom this software is for, how should you communicate, what should you expect as a user, everything about social aspect, maintenance (which is out of scope of legal definitions of the software, but which made FOSS that appealing).

I've even seen cases where the author changed the license (used "legal measures") to prevent further community from forming around the software (to decimate users, to make the software less appealing to FOSS community), because it was too overwhelming to respond to everyone. Instead of using direct measures (social statements of some kind), they used license as a community control method. The author didn't really want to change the code license, they just didn't know other means to achieve different social expectations/behavior they want.

https://www.debian.org/social_contract

>I wonder if this always used to be the case

As written in the article of discussion, it used to be, well, quite a mess. There wasn't an established social expectation that you can ask author to do something, and they will do that. The whole software ecosystem was 100x smaller, and most of the users were tech-savvy. The author released the software somehow, this v1.0 got updated my "many" people (back than many meant 3-4-5), and then, after quite a while, it made a roundtrip back to the author, for which they "officially" released v1.1.

That's it, more or less. If no more bugs found, the software was considered as finished.

The "support" is not only the maintenance burden which (sometimes) could be solved for money. It's also the features that the original author just don't find useful at all, but others may want to have.

If I don't have Mac, never used it and don't plan to buy it, why would I want to accept contribution to support this platform? It's useless for me, I won't be able to test it (and it will break sooner or later), and once the code is accepted, it's usually assumed that it would be maintained by the application author, not the code contributor (unless additional CLA is signed, etc).

  - FOSS applications don't have to be distributed publicly — that's only the common social expectation
  - FOSS does not imply that the code should be available for non-customers. The developer decides who is the customer.
  - FOSS is *encouraged* to be sold for money, *you can sell others' software, even if it's originally free of charge* (see https://www.gnu.org/philosophy/selling.en.html)
  - Open-source licensed with non-free license is still open-source, although non-FOSS
  - You, as a developer, should not be ashamed to choose non-free open-source license if you want to earn (more) money on your software or apply additional restrictions for your benefit. It still could be copyleft.

> The author is making it "for people, for society, for everyone around them, interested in developing the project, adding new features (especially those I need), and improving it in every way for the benefit of all users. After all, if that's not the case, why even publish it?"

This, however, is just a most common social expectation of FOSS, but far from the only case. Lack of mention of this distinction between technical and social open source is the main cause of disagreements, disputes, and, ultimately, burnout due to misaligned social expectations.

I used to have to explain the problem and the difference to an outraged public, but recently I came across an article by Jeffrey Paul https://sneak.berlin/20250720/the-agpl-is-nonfree/ comparing open-source code to a gift! My explanation boiled down to:

"Don't like the gift, it doesn't suit you? Throw it out and forget it!"

You explicitly told everyone that you can do that, and when others do that, you become sad.

To be honest, I think this is because many encourage only FOSS licenses as by definition of GNU, and choosing a custom non-"free" license (which could be still copyleft, but with some restrictions for which the developer care) is usually considered as a "bad move" from the abstract community.

Why only start? Moreover, you're encouraged to sell other's people free (as in beer) software, if you want to.

https://www.gnu.org/philosophy/selling.en.html

>if you are redistributing copies of free software, you might as well charge a substantial fee and make some money. Redistributing free software is a good and legitimate activity; if you do it, you might as well make a profit from it.

FOSS projects does not have to be publicly available somewhere on the internet. That's only the "common expectation" (see all social aspects from my other comments).

I sell others' software, successfully. And contribute back, both code and money to the projects I sell. And everybody are happy! I wonder why this isn't used much often.

It's very long and poorly structured, but it's valuable from my standpint. Don't read if you value your time.

---

Your article only covers the most well-known, largest, and established projects that meet both the technical definition of open source (open source code, under a free license) and the social definition (code is publicly available to everyone, free of charge, with both bug fixes and simple bug reports encouraged), and are also economically attractive to businesses (more on that later). There may be a couple of hundred such successful projects. A drop in the ocean of open source.

From my experience, I believe that the lack of mention of this distinction between technical and social open source is the main cause of disagreements, disputes, and, ultimately, burnout due to misaligned social expectations.

---

FFmpeg vs. AWS (spoiler)

https://x.com/FFmpeg/status/2024934828961923514

This can even be seen in your screenshot of AWS vs. FFmpeg in the article: the author of the FFmpeg Twitter account repeatedly believes that corporations owe something since they use open source code, even though the license doesn't obligate them to do so. Moreover, when Google launched its fuzzing program (objectively the most advanced in the industry), which automatically identifies and reports security issues (which is a significant contribution in itself), FFmpeg wanted not just code fixes but also Google to pay them for the maintainers' time!

We came up with LICENSE.md, but we didn't think of SOCIAL.md.

---

In other words, it's a digital version of the tragedy of the commons, in which the cycle repeats itself from project to project:

* Initially, some technical open-source software is created, under a free license, to solve a specific problem, either for oneself or for a limited number of people.

* First, a few users appear, saying it would be nice to have such-and-such a feature—the authors implement it, since it's not that difficult and generally useful.

* Then, as users grow, handling their requests becomes tedious—often, features are offered that the author will never use, or support for a platform requires a significant amount of code that the author isn't interested in, and they can't test the software on.

* The worst thing is when the software becomes popular (especially if it works reliably and is unique in its kind) and some other large project starts using it. Congratulations, your project is now a public good. In a single day, the burden of social responsibility for any bug or security issue falls on the shoulders of the author/maintainer, because it now affects not only the initial limited user base, but potentially millions of users of other software that relies on both your code and you directly.

Until the final stage, you could sit down, think, and determine what exactly you're doing, and take steps to prevent this or that scenario (or, conversely, develop deliberately toward that scenario). But once that happens, it's too late to do anything. You've effectively become a provider of social software, with all its advantages and disadvantages, and it will be very psychologically scary to say "no" to people and somehow get out of this situation in the short term.

FFmpeg, for example, still refuses to recognize itself as social software, despite being used by hundreds of large projects and being the default distribution on desktop Linux systems.

---

How is this expressed? (spoiler)

FFmpeg's stated mission on its website is as follows:

FFmpeg is the leading multimedia framework, capable of decode, encode, transcode, mux, demux, stream, filter, and play pretty much anything humans and machines have created. It supports the most obscure ancient formats to the cutting edge. It doesn't matter if they were designed by some standards committee, the community, or a corporation.

This conflicts with the security needs of a wide range of users: the more multimedia formats supported, the wider the attack vectors available for users of any software that uses ffmpeg: video players, browsers, instant messengers, preview generators, etc. A security flaw in an old codec could lead to browser compromise if a user simply visits a page with a malicious video.

This isn't a hypothetical danger—errors in file format demuxers and multimedia codecs are among the most commonly exploited. Here's a very recent example (Dolby decoder on Android), and here's a more high-profile and complex one (JBIG2 to PDF on iOS/macOS).

It's assumed that programmers in third-party projects using the library have sufficient knowledge to correctly and securely configure the library in their software, as FFmpeg's primary goal is to ensure playback of a wide range of files, not to address the needs of developers who use the library as a dependency or the end users of that third-party software.

According to the ffmpeg Twitter account, its use on AWS isn't a sign of the library's success or quality, something to be proud of, but rather a significant psychological burden for the project, as the company provides neither funding nor human resources. One can only expect even more tickets in the event of problems, and a lack of fixes for bugs, which Amazon fixes only internally, rather than contributing back to the project.

---

If a project doesn't have any obvious distinguishing features that indicate it's not social, it's assumed to be so by default.

If a project is on GitHub, has a readme and an issues section, the average user or programmer will assume the author is writing for people, for society, for everyone around them, interested in developing the project, adding new features (especially those I need), and improving it in every way for the benefit of all users. After all, if that's not the case, why even publish it?

I used to have to explain the problem and the difference to an outraged public, but recently I came across an article by Jeffrey Paul https://sneak.berlin/20250720/the-agpl-is-nonfree/ comparing open-source code to a gift! My explanation boiled down to:

"Don't like the gift, it doesn't suit you? Throw it out and forget it!"

Money.

If you're making something that doesn't feel like a product (for example, a library that solves a specific problem that a non-programmer wouldn't be able to use, or even need), it would be a great success to get anything at all.

Have you ever considered donating (money, improved documentation, or code fixes) to such widely used and significant projects as glibc (a C library), FriBidi (a library for working with right-to-left scripts: Arabic/Hebrew), or libusb (a cross-platform low-level library for working with USB devices)?

Each of these libraries is extremely popular and has a user base of billions of devices. They're usually the ones people think about when something isn't working.

When I read articles like this one (remember the title: "How Can an Ordinary Developer Get Into Open Source and Is It Worth It?" The examples include free products created by corporations, or commercial products initially oriented toward open source, but open source), and I always wonder: what does open source even mean to the author? It seems to me that today it's analogous to an "open source business," with a hierarchy a la the cream of society (whom we'll be writing about, where it's prestigious to contribute your code) and some homeless people with their libraries at the bottom, who aren't even worth touching.

>>(quote from the article) I personally met someone who dragged out a PR for a week because he didn't understand what a CLA was or how to sign it.

Do you understand what a CLA is? Perhaps you should explain it to the reader, otherwise they might not want to contribute to such a project after the explanation? Perhaps the idea of transferring their copyrights to a corporation isn't appealing to them at all? Or maybe there's a code maintenance obligation for X years, and they're not even aware of it?

The presence of a CLA, if it mentions transfer of rights, usually means that for once, it's safe to shift responsibility for solving your problem to the maintainers by creating an issue, rather than digging around in the code. People won't complain, because they're working on the project for money and that's their job!

Could we maybe invent the exact definition of this model? Because "open source" for me (and in general) is definitely not that.

Two examples:

1. Remember GitHub before free private repositories: lots of technically open source code not intended to be used by anyone besides the author, which was published only because the author don't want to pay to make it hidden. You're free to use it (given the open-source license), but neither of you have maintenance expectations.

2. GNU not only allows to sell free software, but encourages that, _even if you did not make it_. This is quite rare, to the point that it makes people angry at you when you try to sell someone's software.

Check the Wi-Fi tickets, they are sitting without any replies from the RPi team since 2025. It is broken in these configurations, I decided not to use this strong general term for this case (it's broken only in certain configurations and use cases).

The USB bug (from 2019) has not be fully fixed. They got it much less extent, but did not eliminate the issue.

>Because other vendors are way worse.

There's only a single difference: Chinese vendors don't fix issues in both things they do control and in things they don't. The thing they control is usually a "Distro Build" or Buildroot rootfs hierarchy, which I personally see little value in.

Bugs related to third-party hardware and firmware present on the board gets rarely fixed by both sides.

Don't get me wrong, I'm absolutely not happy with it. I bought Intel NUC, which has Intel Ethernet and Intel Wi-Fi, as my PC with the idea that Intel has end-user support and writes drivers, and NUCs should come with golden Linux support, right? Yet Intel developers still supposed that I had to fix the bug in Intel drivers myself: https://marc.info/?l=linux-pci&m=175368780217953&w=2