In my opinion, Debian has the best open-source governance model out of all the projects without a BFDL. Because it basically emulates it by appointing a single person to be responsible for the entire vision, yet making him still accountable to others[1]. Thus the horror of the "design by committee"[2] is avoided.
I think there's nothing wrong with re-using good solutions that others have worked out instead of building your own just for the sake of being different. That's the open-source idea even, no? Freely reuse and build upon the work of others, so that we don't have to reinvent things again and again.
And yet open source is constantly reinventing the same things over and over again anyway.
I think parent's complaint is that Debian's model has failed to produce good solutions of its own, and while that isn't necessarily a requirement, it does speak to potential limitations of the model
I don't think there's a good way to measure Debian's contributions outside strictly packaging its distribution.
If a Debian developer, or a group of Debian developers, sets out to solve some problem that isn't Debian-specific, the result is (quite correctly) seen as a new independent free-software project rather than a Debian project.
For example, as I understand it the reproducible builds project (now reproducible-builds.org) started out inside Debian, then became a thing of its own.
> it does speak to potential limitations of the model
The parent compared a group of volunteers with the largest open-source company in the world, which is a part S&P 500. No other Linux distribution has a comparable amount of resources. Even Canonical is following the RedHat's lead (systemd, Wayland, PulseAudio).
RedHat wasn’t always as big as it is now. In fact, it was likely smaller than Debian, in terms of manpower, for some time. I suspect the total number of package maintainers is still higher on the Debian side.
Probably at least partly by necessity. Not everyone participating is doing it as their FT job. I'm sure that RedHat is paying a lot of devs to work on these things as a full time job. Even just integrating software from others as packages, etc.
The way I understood the parent is that the Debian model didn't actually solve the problem it was suggested as a solution for. It merely offloaded the problem to someone else. In other words, it has a dependency and therefore is not a complete solution. That's how I understood it.
> It merely offloaded the problem to someone else. In other words, it has a dependency and therefore is not a complete solution.
Debian isn't more dependent on RedHat than any other Linux distribution is. It has nothing to do with the governance model, but rather with the fact, that multiple open-source solutions created by RedHat employees and firstly released in Fedora have won as currently the best.
In terms of out of the box stability and support? Yes, absolutely.
The power and flexibility of Linux comes with the cost of a much lower floor for stability than proprietary operating systems. You can make a rock solid system using Linux, but that requires nontrivial effort and knowledge. I have yet to see an issue on my personal Windows and macOS machines that approached e.g. package management hell on Linux, in terms of complexity and frustration.
For examples of what open source projects look like when they have the backing and resources of large companies, look at LLVM versus GCC, BoringSSL versus OpenSSL and CentOS versus Ubuntu. "Better" would be too broad a description, but if you qualify it to the narrow scope of stability, then yeah I think proprietary resources generally come out ahead. I also don't think that is a controversial observation.
Except my understanding is that the amount of manpower involved in the Linux kernel is greater than that involved in the Windows kernel. (Does Apple do kernel development at all?)
In other words, you think if Debian had a larger, more vibrant community it would take in fewer "good solutions" from other projects and instead decide to create its own alternative good solutions in house?
I think this is the first time I've heard someone critique a model for encouraging anti-NIH syndrome.
And yet open source is constantly reinventing the same things over and over again anyway.
That's endemic to programming and the fields around it, even in closed source. I don't think it's a problem of open source, though open source might enable it in a few ways.
> I think parent's complaint is that Debian's model has failed to produce good solutions of its own
Debian must be producing very good results, and doing so consistently. Otherwise Debian wouldn't be either the most successful linux distro or the distro that is forked by the vast majority of leading distros.
> I think there's nothing wrong with re-using good solutions that others have worked out instead of building your own just for the sake of being different.
But that's exactly what Red Hat has done in a lot of situations. The main example I can think of is systemd. It was built to solve problems that really only appear on enterprise production systems, sadly it got adopted across the board for systems outside of that niche. Essentially it's taken what was a working system (sysV init and friends are very, very simple to configure for 90% of the desktop configurations) and replaced it with something that somehow needs continual firefighting.
Back to the original point: Not only has systemd reinvented sysvinit, but at this point systemd has reinvented from scratch:
The claimed reinvention from scratch of a text editor, and the nice command, are in fact nothing of the sort. One is a means for invoking a text editor (of one's choice) against particular configuration files, no more a "reinvention from scratch" of a text editor than the vipw command is; and the other is one of the several settings specifying eventual service process state, and is no more a reinvention from scratch than the Service Access Facility's "ulimit" built-in was in 1988.
This is one of the standard parts of service management, and service management toolsets all have to do it, either employing nice or their own mechanisms. Gerrit Pape's toolset does it with the -n option to chpst, for example.
Ironically given the subject of Debian, one can look to the Debian package archive (or indeed the FreeBSD or NetBSD ports tree and some others) to see lots of actual reinventions of a text editor.
Similarly, the claim that cron is only just now being reinvented from scratch looks rather ill-informed given the existence of tools such as Uwe Ohse's uschedule and the multiple "cron" tools, many of which reinvent the design in significant ways (Bruce Guenter's split of scheduling, spooling, and updating into separate services being a notable example); and given the fact that Paul Vixie's "original" PD Cron was actually itself a from-scratch clone.
> Ironically given the subject of Debian, one can look to the Debian package archive (or indeed the FreeBSD or NetBSD ports tree and some others) to see lots of actual reinventions of a text editor.
> Similarly, the claim that cron is only just now being reinvented from scratch looks rather ill-informed given the existence of tools such as Uwe Ohse's uschedule and the multiple "cron" tools, many of which reinvent the design in significant ways (Bruce Guenter's split of scheduling, spooling, and updating into separate services being a notable example); and given the fact that Paul Vixie's "original" PD Cron was actually itself a from-scratch clone.
My response to both of these are, can you point out any of them that are part of a monolithic system that replaces the traditional PID 0?
Or are you talking about people reinventing small parts of the general system? Yes. UNIX allows people to swap out software for other software. In the original use-cases though, the editor(1), cron(1), and nice(1) were at no point conjoined with the boot menu system, or PID 0.
Indeed, there is a fundamental choice between someone building a replacement for one small part of the general system, to make their life easier, and building a replacement for the entire init system.
Last time I was a debconf, one such decision was basically 20-30 interested people sitting in the room and the speaker says "We need more people if we want to maintain and develop X, or could switch over and use Y. What is the progress on packing Y?". It was a rather simplistic process by the developer who is doing the work and anyone interested that wanted to show up. Debian leadership rarely get involved in such decisions.
And RedHat takes projecys ftom upstreams they don’t contribute to and bundle them in their systems. Sorry, but this is a particularly mean spirited attitude. The open source model has always been to share your work On one hand and selectively use others work yourself where it makes sense. That’s what opens source is for. It’s what it means. BSD is free to commit their resources to those areas where they feel they can offer value or meaningful differentiation, and they do so.
Every design either comes from one person, or it comes from a committee. A project like Python has long since scaled far beyond the capability of one person to feasibly design. The same is true of any other major (or minor) programming language. Vague anxiety about design-by-committee is always in vogue, but it doesn't do us any good.
If it did, a virtual BDFL would have been able to stop the whole systemd vote from happening, declare that systemd would be the default going forward, and require that some number of developers come forward to take maintainership of alternate init system if init decoupling were to be a requirement in Debian. And Debian depends on a human WoT anyway. So a reasonable amount of developers saying, "Ok, we'll make sure everything can work on multiple init systems going forward," would be enough. And if that turned out to be untenable, they could make a different decision down the road.
But that couldn't have happened because it would have gone against the democratic spirit of Debian.
Compare to what Linus did with the pull request for kdbus. He said he trusted his maintainer who did the request, but also pointed out the amount of work and problems that could come from maintaining it. Maintainers argued, but ultimately it was the maintainers who retained agency and who ultimately maintained a sense of trust among each other.
Now imagine if instead there had been a vote of Linux users/foundation members/whatever to decide whether to include kdbus. Linux would have bled developers regardless of the outcome. Because that model of governance would have given them less agency to make decisions about the direction of the project.
My point was that a "virtual BDFL" works better than the "design by committee", not that it works better than a real BDFL. It doesn't. I completely agree with you.
Design by committee is avoided by using designs of someone else.