> Integrating Zopfli into the npm CLI would be difficult.
Is it possible to modify "gzip -9" or zlib to invoke zopfli? This way everyone who wants to compress better will get the extra compression automatically, in addition to npm.
There will be an increase in compression time, but since "gzip -9" is not the default, people preferring compression speed might not be affected.
To add them to the "wiki", you'd have to be able to edit the wiki. You cannot. I rather wanted to edit the "Liar Paradox" (sic) page, but there doesn't seem to be any way to do so.
What I do is a greater waste of time -- I have a separate browser profile for each individual site that I might log into, and javascript is only whitelisted for that one site in that profile. It's a real pain because whenever my browser adds a new config option, I have to update the settings in each of the ~20 profiles.
It has saved me a few times where some rogue javascript tries to redirect me to some unexpected site, and the destination site simply doesn't load.
dude
what
how do you have so much free time
my lazy ass just has ublock origin with some lists enabled that my even more techbro help me set up and it automatically stops me from visiting suspicious websites
this feels like way too much work
I just want every new machine to have my extension settings, but then it's four hours later and I'm trying to check if some policy file was obsoleted in version 60
VIM seemed to have fared well under the new leadership, despite not being able to control the timing of this power transfer. Maybe other BDFL projects would be inspired by VIM's experience and setup successors early.
You need someone to say 'no' to all the stupid ideas, and also to the occasional good idea to stay focused. Committees and communities are quite bad at that. IME the BDFL model has mostly worked best for open source software development, unless the BDFL is a complete ass of course.
(also software projects don't need to be democracies, e.g. people won't starve or sent to the gulag if things go sideways)
One of the most powerful ideas I've come across is Arrow's impossibility theorem, which basically states that you don't get a lot of nice group choice outcomes without a dictator in the mix. It's a math formulation, so its not commenting on the realities of a despot, but rather, someone's choices will always dominate if you want a certain set of properties in the decision making.
It's the best, when you find one. But the approach is also the riskiest. You may not even pick a BDFL to begin with (I'm sure many of us can name certain repos overly held back by a bad or muddy vision, or being overly conservative with feature/pull requests) . or that B fades away for any number of factors. Committees sacrifice that cohesive vision and agility for being able to have some checks to potential rouge actors.
> Braam really took Neovim personally and got better at getting stuff into vim that he wouldn't merge before once neovim was arround as a competitor. I really lost track of vim in the last years because neovim is just a solid platform with an active community.
I think that's the answer - the specific makeup of any given team isn't as relevant as competition which spurs competitors to either keep up or the more successful upstarts to take over.
> or being overly conservative with feature/pull requests
We saw some complaints about a repo like this I forget for what project some weeks back here on HN and it came down to, people dropping a PR and then the maintainer left holding the bag if something goes wrong, having to maintain someone else's code, which can become a problem if its a completely new feature they didn't implement or want, but users wanted. The other case is, they fix a bug, then disappear, so if the maintainer has feedback, now they have to take time to check out the person's code, update it, out of their current planned work.
I wonder if more open source projects would benefit from adding plugin architecture so people can do those one-off features as plugins without "tainting" the core project.
Honestly in open source I'd argue it's not. If an OSS project has significant usage, if BDFL struggles/etc - community forks can put the project back on pace. NeoVim is the classic (successful) example that gave us a great alternative while also nudging the BDFL into the modern age.
Not necessarily. Sometimes people infiltrate projects with the intent of sabotaging them. This may be done by causing a controversy, or else making bad technical decisions on purpose.
I think in the case of Linus, you REALLY have to be strict. I mean, its arguably one of if not the most used pieces of software deployed in enterprise and globally for all manner of use cases.
Yeah, “dictator” was probably the wrong word. The characteristic of an actual dictator (even a benevolent one) is that they can enforce their will through violence if needed (benevolent ones usually don’t, but they could).
As quote goes, “I thought we were an autonomous collective.” Humans have some sort of tribal or pack instinct; if we want to do a project, we’ll often naturally form up around the person who’s doing it, willingly and without compulsion. The leader is the leader because everyone agrees they are doing good enough.
Open source project is sort of an ideal form of this. Unlike physical projects, the ability to fork for free means that the leader doesn’t even have the implicit moat that a potential alternative leader needs to take the current work-in-progress away from them.
Unless your software deals with tracking people within an organization that will of course comply with the political parties that rule the regions where there software operate.
If Vim tracks you then that’s a willfull act that breaches trust.
IMO no governance model can defend against supply chain attacks.
IMO you shouldn’t try to fix things with governance model which it doesn’t fix. Use a governance model that leads to good governance. In technical and creative work single highest point of authority is best.
Not because they have perfect knowledge or are the best but because dictator led models lead to best alignment - which is something you simply need to execute when performing a complex task with many stakeholders.
Dictator led models aren’t best for everything. But for complex tasks with specific fixed scope with multiple concurrent contributors it seems to be the only model that works (if there are case studies as counter example I would love read on them! I.e. complex task, more than 10 contributors, non-dictator governance).
Hmh, I don't have a case study at hand, but there are many reports (and management self-help literature) where teams are shown to be the superior approach to complex situations, especially in software development. Furthermore, considering that there are only about 50 identified open source projects out there with a BDFL [1] and only a few of them are clearly best-of-breed, while there are many best-of-breed projects that do not use a BDFL I'd wager that the perceived superiority of BDFL can at least in part be attributed to the perennial hero worshiping we like to do.
Any tiny project on Github, Gitlab, ... which is maintained by one person but accepts PRs and feedback from outside contributors is essentially a BDFL project.
The single project owner decides what goes and doesn't go into the project by merging or rejecting PRs. People are still free to maintain their own forks with contributions that are not accepted into the main version.
In a way, the entire Github workflow is built around the idea of BDFL managed projects.
IMHO - No - having individual contributor workflows is diffenrent thing than aligning 10 people. The question is not who gets to do the decisions but how the team aligns itself and coordinates.
It’s an accurate observation that single contributor projects work well since then there is no need to spend effort in coordination and communication.
> The question is not who gets to do the decisions but how the team aligns itself and coordinates.
...IMHO it's the other way around, somebody needs to do the difficult and unpopular decisions exactly for those hopefully rare situations where the self-coordination within a team fails (and doing that in a way that doesn't piss off people in the team). In the end, contributors to an open source project are also just a very loosely coupled team.
'Unpopular' decisions are much easier to do in projects that have a universally accepted and respected BDFL (ideally the project founder) than in most 'commercial' teams led by random 'management-caste' peeps.
“many reports (and management self-help literature) where teams are shown to be the superior approach”
Isn’t the manager himself the BDFL - or a part of a BDFL led chain of command - for the team he is empowering in this case?
He does not give out the organizational governance-authority just by empowering the team.
Having a BDFL does not imply micromanagement or not empowering teams. It’a a different granularity role than implementing day-to-day issues.
There are people who are really talented leaders. The problem are bad leaders - not the governance model IMO. And this is not a “no true scotsman” argument since effective leadership is a documented and observable phenomenon.
Lack of authority is probably better than poor leadership but not better than good leadership (e.g. legendary John Kelly of Skunkworks fame for an fairly well documented example).
Good point, and I wholly agree that there are really good leaders out there. But I wasn't trying to say that leaders are necessarily bad. I was trying to say that BDFL setups are not necessarily "the best" and there are good reasons to think that other forms of governance have just as good or even better track records. We do not talk about them that much because, I think, we just like hero stories and they are easier to tell with BDFL than with groups.
One big question is why presumably "open source" projects still consider in 2025 to be acceptable to be hosted on Github (especially for those with the most important contributors not being USian).
Saying "no" is the easiest job in the world, and committees are pretty good at it. That's why we have decades-old design failures everywhere, because saying "no" to an improvement is so much easier that doing the actual governing and resource allocation to see it through, especially with volunteers
And given the article describes big fails at basically every aspect of project management (from github account to money and website), not sure where you see the benefits of the supposed "focus"
I don't know it seems to me that committees are famously bad at it, so that we use "design by committee" for something that refuses to take a single direction and either makes bad compromises or says "yes" to all options.
Those that are paralyzed by fear of change and say no to everything, and those that are afraid of offending people and say yes to everything. Both are counterproductive.
I agree, committees are good at saying no. They tend to say no to two not perfect ideas and then force a consensus containing most often the worst aspects of both original approaches. The good news is that the result is so bloated that can‘t be changed and so provides a stable foundation for years of misery.
There are counter examples of course but the power dynamic of committees is not conductive to results that have properties desirable in software.
When I think about the two models, I have Linux as the dictator type and XML as committee designed. Both are functional enough, but the while so few data points are hardly conclusive, I think it's generally indicative.
I'm not a particular fan of XML, even if it's functional enough to get the job done.
Of course you have to find a dictator that is ready to invest all the time and energy to care for a project over a prolonged time and is actually capable of doing so while avoiding to alienate the user base. That's a pretty tall order.
It depends on your motivation. Probably a lot (many, most?) committees can just sit pretty and try to do as little as possible. But a lot of software projects exist by getting attention, and they tend to do that by adding features. A lot of FOSS maintainers find it super hard to say no. For some anecdata: I have a small/medium project and I've found that just the energy requirements of really thinking about everything everybody proposes are pretty high. I could just say "yes", but then I'm on the hook. I could also just say "no", but then I'm discouraging people and not really giving them any information about how to contribute productively--this would be something like, "sure we could add a flag to turn video upside down, but I'm concerned that putting this kind of functionality in flags means we'll have a UX of 1000 flags that no one can remember or use; should we start considering building another place to put this kind of functionality?
> just the energy requirements of really thinking about everything everybody proposes are pretty high
Indeed, that's why it most often results in a no (your ending quote is just a polite way of saying no), and you're right about the discouragement part, and that's one of the reasons forks like neovim appear. (and unfortunately often you can't "motivate" your way into creating enough time for all that extra work either, so with the best intentions... no it is )
In your first comment you seem to think that the BFDL for life is not so good. Now you are saying negative things about committees. So what do you think would actually be a good way to run an open source project?
On the contrary, saying No to an otherwise great contribution that doesn't fit into the longterm vision of a project for one or another reason is the hardest thing in the world.
Not sure about mobile apps, but in Discord desktop there is an option under "settings -> notifications". Your browser may also have notification settings that would help.
This changes the attack from a 0-click attack to a 1-click attack.
Is there a corresponding proposal for C++? The earlier thread mentioned that "C++ doesn't have this yet", but I am wondering if C++ has enough template magic that it's able to do it through libraries without changes to the language.
I am a fan of these Famicom/NES synthesized sounds, they have a flavor that is rarely found in modern game music. There are a few musicians who does rearrangements of songs for playback on the Famicom, example:
https://hachyderm.io/@joschi/113914355705581670
Second post in that thread has some demo output.
reply