We take for granted the ability to install anything via our package managers, but it's made possible by efforts of a vast number of contributors who often just like a piece of software and stepped up to allow everyone else to use it too. Too often they get zero recognition for their efforts.
I'm doubly grateful because I'm also an upstream maintainer who doesn't have to try to keep up with all the various packaging processes.
If you want to support them, the next time some software is unavailable or lagging behind in your distro, see what you can do to help!
I actually believe much of the Docker hype can be attributed to this. Why bother learning packaging when you can just script something and throw it in a container.
Now I just use Guix on any distro for my up-to-date/custom software needs.
I'm curious  which aspects you find make the Debian (and Ubuntu?) system particularly difficult. Specifically, I wonder if those aspects are difficult by design, in order to "force" effort on the part of the packager to extract benefit on the part of the user or distro, if they're arbitrary, or, perharps if they're by-design but misguided.
 No horse in the race.. mostly an end-user whose packaging work is limited to internal-use-only.
It's been quite a while since I looked at it, but the documentation was fragmented and not up to date. Things have gotten better now you can use git-buildpackage , but it still feels arcane.
Challenge - take a package like wget and try to update it to the latest version from upstream Git (or whatever). It should be one or two commands but I've never been able to make it work easily. It's even harder if you're trying to port something across from Ubuntu or to use a fork like wget-lua 
I assume none of us is even talking about this case. That is, a trivially working .deb could provide little more functionality than a tarball, so that's hardly interesting.
> getting something to pass QA to get into the archive.
The last part I have no knowledge of, since I only ever put my packages into internal archives. Were there political aspects, or only technical?
For the technical, I'm still looking for (ideally from the GP, but from anyone who shares the opinion), specifics.
> the documentation was fragmented and not up to date.
This is a common complaint I hear/read, and I recall it was part of my initial learning investment, figuring out where to go for what information. Now it's mostly bookmarked, and changes tend not to be drastic.
> Things have gotten better now you can use git-buildpackage
One thing I found, repeatedly and consistently, was that every single external (i.e. not from Debian) utility that tried to make the process "better" or "easier" ultimately did the opposite, since it would hide or abstract away an important aspect of the packaging process.
> Challenge - take a package like wget and try to update it to the latest version from upstream Git (or whatever). It should be one or two commands but I've never been able to make it work easily.
I can't recall if I've done wget specifically, but I've done this kind of thing before without much issue, assuming that latest version actually builds and runs on that platform without porting work and without needing a ton of new dependencies (or new versions of existing ones).
I tended to find most of my time was spent in chasing down and re-packaging various libraries whose older versions were no longer good enough.
> It's even harder if you're trying to port something across from Ubuntu
I'm not sure what you mean, since Ubuntu is already using Debian packaging.
> or to use a fork like wget-lua
Certainly forks are going to be more effort, but my experience is that this is true even in their unpackaged state, if they require more exotic (or specific) dependencies be pre-installed, a custom build process, or any porting work. If someone had already done all that work, comprehensively documented it, but merely not translated it into debianization, it would save me a ton of time in creating a custom package.
You can somewhat see the evolution of the python package debianization ("python policy").
Packagers create the glue between the software (which is heterogeneous) and the distro (which is internally consistent). The world without this glue is a horrible mess and a huge waste of time; the old Slackware is a good example. It's thanks to the distro makers that you don't have to spend days collecting requirements and acquiring arcane knowledge just to install a piece of software.
So: yes, those people devote a huge amount of time - so the countless users around the world don't have to. The net time value is positive.
An independent software author (e.g., Ultimaker or Prusa) just wants to reach all "Linux" users at once without dealing with different distribution's policies, and without needing to use the same version of e.g., Qt, that happens to be in a given distribution. And as a user of their software, I want their software on my "Linux" system in the same moment Windows and macOS users can have it.
And from what I have seen there is only a primary alternative being proposed; containers. Have a copy of all needed libraries in every package and leave it to the developer to patch and fix security. Occasionally put a few things into the operating system, but then you have to hope that those parts don't change or you have to make different packages for different version of the operating system.
Applications should only use those shared libraries that come with the Core OS a.k.a. base system, and either link statically to or bundle the rest.
Like an iOS application can only consume what iOS provides or bundle any additional dependencies privately.
The result would be a much simpler and more resilient system (at the expense of some storage and memory overhead, which is the lesser evil imho).
On balance, I agree with the conclusion. However, coming from a non-desktop viewpoint (server, not embedded, though I do sympathize with the latter), I don't think it's obvious that "some" overhead is worth it, nor has it historically been worth it.
At scale, size can matter, though, like I said, I think today, nobody would even notice.
It's tough to "fight" that history, though, so we go through the pain of even more overhead of full virtualization before cutting it back with OS-level virtualization (a.k.a. containters) and (re-)declaring victory.
> for so many different package repositories and packaging formats?
How many are there, though, really? In theory, the number is unbounded, but, in practice the number of distros is modest, the number of popular ones is smaller, and the number of unique packaging formats even smaller.
Although a sibling comment alluded to it with distros being internally consistent, I wanted to unpack that a bit more.
Specifically, one benefit I've found as a "user" (sysadmin/devops) is that of well-defined dependencies. This isn't inherent to packaging, but it tends to be a feature of the more mature systems and distros.
The other benefit is that it provides a more universal mechanism of traceability and, thereby, at least a path to reproducibility of builds. This has implications for security, of course, but also for debugging.
Sometimes though, people do it...and it might even be automated.
BTW since Harrison Consoles have a commercial version of it (MixBus/MixBus32C) and are actively contributing to Ardour, I wonder if they are also supporting it financially.
BTW I've switched from plain Ardour to MixBus a few months ago, and I'm not sure why but it produces much better results for me.
The better results are probably due to Harrison's EQ and console bus emulation.
EDIT: Not to downplay Audacity which is also awesome, it's just not meant for the same use case.
For example, we use verdaccio (https://www.verdaccio.org/) as a private NPM server. IT was so mindblowingly simple to get a private server working that, when the opportunity presented itself, we felt compelled to donate: https://opencollective.com/verdaccio
In this case, it seems that there was an older abandoned effort (sinopia) and the original developer Alex Kocharin (https://github.com/rlidwka) stopped. Juan Picado (https://github.com/juanpicado) picked up the mantle and given how NPM is moving fast and breaking things it's great to see someone is keeping up with the open source solution.
Nico Sturman used to be one of the project leads, but it's been a while since I've kept up with who runs it now.
If you think a FOSS KiCAD "competitor" with a solid and well thought-out library design and good usability should be supported, then check out his Patreon page (or his BTC address). Or – of course – contribute code.
Here you can find a LibrePCB introduction video from this year's FOSDEM: https://fosdem.org/2018/schedule/event/cad_librepcb/
Apologies if he mentions it in the video -- I'm at work.
Not every open source project is built the way a person thinks it should be. The only way to know if an alternate viewpoint is better is to build it and find out. Other times a person just wants to build it for themselves for their own reasons. Either way, variety can be a good thing. One day an alternative may just replace your favorite piece of software and then you might ask why the creator started from so far behind all those years ago...
There are probably as many reasons as there are developers.
I was hoping to hear about his opinions of the shortcomings of KiCAD and where LibrePCB improves on them. It would certainly help someone like me decide whether to fund him on Patreon or not, seeing as I've donated to CERN for KiCAD development.
Edit: I've found his reasons in his slides - https://www.fosdem.org/2018/schedule/event/cad_librepcb/atta...
2015 article: https://www.informationweek.com/it-life/ntp-harlan-stenn-and...
And more support is most definitely always welcome!
It's had its share of bugs, but the amount of work he has put into it over the years is pretty incredible. Most other video editors for Linux don't even come close, and it recaptures a lot of the lost glory of Windows Movie Maker before it was rewritten and made ugly.
cough-- I also very much like pizza: https://brynet.biz.tm/wallofpizza.html
But is it Pizza Pizza?
Ross Mason - Founder of Mule Soft. He built Mule which is Open Source and helped many companies better integrate services.
Joe Walnes - Joe is a beast. He's contributed and created many Open Source projects. websocketd, smoothie, xstream, webbit, and many more.
Rick Hightower - A very smart guy who use to blog about technology that helped many many people. He also created Boon a JSON parser, qbit, and many other frameworks. Because of all of his hard work, he was also made a Java Champion.
I could name so many more folks. Honestly, it's amazing not more people are acknowledged for their efforts.
We're now a team of about 30 people with 10 years of development into the Gluu Server, a free open source software platform for SSO, 2FA, access management:
It sounds though like this is, in fact, a commercial venture.
He is the maintainer of the GNU Bash shell and of the GNU Readline line-editing library.
You can thank him for: normalize.css, sanitize.css, SVG4Everybody, HTML5 Shiv, and the yayQuery Podcast theme music. And many more.
- and -
Natron video compositing software:
Both are great tools with a steady stream of updates.
An amazing self-hosted cross platform file syncing/sharing service. Being based on git allows for (somewhat) unlimited version history. Simple and elegant, really surprised more people don't know about it.
iTerm2 seems to be the favourite terminal of macOS users… at least those that spend a large amount of their time there (especially with its native tmux support).
(I support Joey on patreon, as I use git-annex quite a bit)
* Calf: A small group of devs producing a set of high quality audio processing plugins. https://calf-studio-gear.org/
* Ardour - pretty well known I think, but only in the narrow cross-section of audio geeks and Linux geeks. https://ardour.org/
OpenBSD core developers.
Former built almost all of ScalaJS and the latter built ScalaJS-React.
It's inspired a lot of KotlinJS as well.
We recently created a Patron account, if that helps:
Great framework to build highly scalable, low latency service (developer friendly). It would be great some detailed tutorials and documentation about its internals.
Git for Windows, Audacity, Python are all good examples where people have put in a lot of work.
On the Microsoft side, whoever's porting OpenSSH is pretty awesome, too.
eg I just pointed out the project (DB Browser for SQLite) that I've been helping out for years. We're widely used, people say very good things about us, and we could definitely use more funding. ;)