I'm aware that the things I'm about to discuss aren't very important; mostly I just want to organize my thoughts, and perhaps vent a little. If you want to read something that I consider very important, go read this, this, this, or this With all that said, here are some nice fancy pullquotes:
Overbite Chrome is no longer supported due to Google's extension format changes. It is no longer compatible with Chrome 24 and up… For now, use the Public Gopher Proxy (below).
As a consumer, yes, you have lots of choices in which Linux you use.
This does not mean Linux is in any sense _about_ choice, any more than
because there are so many kinds of cars you can buy that cars are about
We will not be proceeding with this feature request. We recognize that there is a significant number of you who will be disappointed with this decision, evidenced in part by the many stars on this issue. We debated it extensively, both inside the team and with members of the community. In the end we decided that the WontFix resolution was more in keeping with Chrome's core value of simplicity (https://www.chromium.org/administrators/frequently-asked-questions).
-- miket, representing Google in a chromium bug about restoring side tabs
(In reply to Miguel Hernandez from comment #108)
Just dropping ALSA support out of the blue doesn't fix anything, Gian-Carlo,
and it can be added back for now with absolutely no overhead.
Installing Pulse Audio fixes all the known issues with the ALSA backend.
-- Anthony Jones, representing Mozilla in a bug about firefox being broken on all ALSA systems
By most accounts, somewhere between the majority and the vast majority of Python code targets Python 2. Some even claim that all of Python 3.x put together is about as popular as Python 2.6, the outdated version of Python 2. At least personally, almost all of the python I've ever written personally or professionally uses Python 2.7 or earlier.
and finally, to balance all that out, surprisingly detailed documentation about the rationale for and how to cope with (with eyes to both forward and backward compatibility) the changes brought about in OpenSSL 1.1.
I guess the real question I want to ask then must be: What is the role of the user in shaping the software they use?
For what I'd call "personal" projects, which exist to solve a workflow that the author encountered, I think the question itself suggests an answer. Since the author is the primary user, anything useful to them goes in, as does anything else that they may not use but are comfortable supporting. Since it is a "labor of love", feedback from users technical and non- alike has an advisory role. There is an important distinction, though: technical users can implement these features, and, if they are rejected, go fork off their own project. If the original project is being truly unreasonable about code inclusion, this fork can even become the new authoritative version. But this doesn't happen very often.
Some projects, whether intentionally (e.g., LLVM) or by accident (e.g., Linux) will grow beyond this scope (in those cases, vastly so). The question then becomes murkier. The two projects I've chosen for example here are both, I would say, "fork-proof" - LLVM has a very lenient code acceptance policy (see: all of the ghc-specific portions of the backend), while Linux has an extremely powerful module interface against which things can be built that do not merit inclusion into mainline. A user could fork LLVM, or Linux, but their version is extremely unlikely to become authoritative. Even if one does become authoritative, or close to it, that decision may also revert if the new fork does not live up to the quality standards of the old (I'm thinking about ffmpeg/libav here).
Needing to preserve existing quality standards is compounded by these projects having enormous codebases. And this, in my estimation, is the heart of the problem. To pick new examples: I, someone technical and already knowledgeable about systems programming, could in fact fork firefox or chromium and add in new features (as upstream would put it; I would probably call it fixing what is broken). Upstream does not want these changes, as alluded to in the above quotes. So I would have to maintain my own changesets on top of master, in perpetuity. I could probably even do this: I'm a maintainer, I've carried (sometimes quite extensive) distro-specific patches before on large codebases. But my version will clearly never become authoratative, for a variety of reasons, and the time commitment will become quite large.
In the case that prompted this post, I'm upset because neither major browser will adequately perform the tasks I need them to due to removal of existing, working code. (And again, I'm not without perspective here; I understand that there are much bigger problems in the world, even in the open source ecosystem, that more urgently require attention.) Most users will not have this problem: ALSA-only users will migrate to chromium, and treestyletabs users will stay on firefox, and the intersection between the two groups will be small.
There is little more immediately frustrating to users than breaking their existing setups, and so I want to relate this back to systemd. There's a lot to like about systemd as an init system (and anyone who says otherwise is exaggerating due to being upset for the reasons described above), and personally I'm glad someone has decided to care about the udev code even if I don't agree with how. And none of that should affect me at all, except that it must: large, important projects forced systemd-only (much like firefox is doing with Lennart Poettering's other project right now...). And while converters exist, and people more upset than me are trying to fork Debian (link intentionally missing) without it, the reality is that when Debian decides that maintainers don't have to take patches to add SysV initscripts, there isn't anything I can do about it.