I think the key thing you are missing here is that most successful open source maintainers don’t lack expertise, they lack time. They are generally capable of improving their projects in any direction they want without help. Mentoring new contributors is basically always a loss in the short term as far as the maintainer is concerned. The project does get improved, but it generally takes longer than if they did it by themselves from scratch, and the improvements might be in an area they don’t much care about. The payoff for the maintainers only ever happened in the long term if the mentorship succeeded and they get a viable independent long term contributor.

For me, the primary issue with it is that I have zero intention of getting locked in to AWS. All the marketing looks great, but I don’t invest energy learning tools I can’t run locally. I’m happy to use AWS but only if I can see the exit. This doesn’t offer near enough to make me break that rule.

I think the key right now is that these are semi-automated scanning processes. Right now, companies like step security selectively publish. So, in order for a hacking group to find out if their malware is detected or not, they have to burn access to a useful package.

None of this is to say I think Microsoft shouldn't be doing something as part of the release process on NPM. However, there is real value in giving more independent third parties a window to do things semi-manually.

The one week cooldown option is not relying on other users to be a canary for you. Its just giving automated scanners a chance to notice. This is the perfect example. I don't think step security found this by accident. They are actively monitoring NPM package releases at some level.

There is something to be said that Microsoft should be scanning packages pre-release. They aren't, though, so for right now there is a ton of value with very little downside if people implement a one week cooldown period.

To answer your question directly, though. If everyone else moves to a one week cooldown, I would absolutely suggest a two week cooldown is a good idea. Being the "slow" moving organization is a good security trade-off so long as you don't take it to extremes and have escape hatches when you actually need to be moving quickly.

There's a really bad implicit assumption in there: Microsoft's scanners have solved the halting problem, so they can tell if a package update will ever flip to malicious mode, or has an intentionally inserted security hole in it.

Of course, this also assumes that Microsoft's internal scanners are much better than the scanners available to the attackers, since any reasonable attacker is going to just run their obfuscated code through a scanner as part of their CI job. (And maybe even use the MS scanner as an oracle by submitting fragments to NPM to see which pieces of their exploit chain get flagged.)

Waiting until everyone else canaries is much stronger, but even that doesn't work on a targeted attack.

> Maybe NPM should run scanners before distributing malware?

I suspect there's always a human checking these results. If NPM straight out rejects an update due to suspected malware, they might end up rejecting correct updates as well. If they grant some "safe" patterns a special pass, they might get exploited.

So I think this only works if you have security scanners that are well-maintained and kept in secret. NPM folks could of course co-operate with some security companies to have a first stab with the releases before they are put to public access. At some point some parties might start want to have monetary compensation for such an arragnement, though.

Look, nobody requested fully automated scanners that are never wrong. A scanner that asks the project owner to sign in with 2fa and confirm the release in case it's been flagged is going to be more than sufficient.

I’m not on X, so it’s good to know I don’t matter in tech. I always suspected. Since I’m a paying GitHub customer, though, I should probably matter to them. The right forum for GitHub to post this is with their status page, their blog, their website, or an email to all their customers. Using any sort of social media for this kind of thing is either incredibly sloppy or very intentionally quiet. Given that my tiny employer has a better incident communication plan than this, my guess is this an attempt to downplay things.

I’ve got the Framework desktop with strix halo. You can reserve memory for the GPU, but it’s straightforward at least on Linux to have the GPU dynamically grab memory as needed. I’ve got my VRAM set to 512MB and regularly use 120GB+for AI stuff.

I wouldn't call it theft, exactly. Presumably work did get done. If I'm reading it right, its just a terrible conflict of interest. The board uses donations to pay companies to work on LibreOffice. That seems totally fine. Some of the board were running/part of companies that rely and work on LibreOffice. That also seems mostly fine? You want your board to represent your community. Then, those same board members directed work towards their companies.

That's definitely a conflict of interest, but I wouldn't call it theft unless you prove the foundation was getting a bad deal. Could the foundation have gotten the work done better or cheaper hiring non-represented companies? That's the question you have to answer to call this theft.

It doesn't seem that is really what the foundation is arguing though, so I'm guessing it wasn't that bad. It seems more their argument is that this violates the non-profit laws they operate under.

> Some of the board were running/part of companies that rely and work on LibreOffice. That also seems mostly fine?

Those board members were elected by foundation members who also work for Collabora, so it was a privilege escalation from contributors to (controlling?) foundation board seats

> It doesn't seem that is really what the foundation is arguing though, so I'm guessing it wasn't that bad. It seems more their argument is that this violates the non-profit laws they operate under.

It may have been that bad. They don't really have to get into the messy arguments of "was this a fair price for this kind of contracting" because that kind of arrangement is inherently unethical, to the point that you can kind of assume it's embezzlement by default (which is why those non-profit laws are set that way).

For desktop usage, I would be absolutely shocked if ext4 isn't the most common filesystem by a pretty wide margin. Its the default on Ubuntu, Debian, and Mint. Those are the 3 leading desktop distros.

No one is going to write a blog post titled "Why I just used the default filesystem in the installer" but that is what most people do. Things like btrfs and zfs are useful, complicated technologies that are fun to write about, fun to read about, and fun to experiment with. I'd be careful about assuming that leads to more general use, though. Its a lot like Guix and NixOS, in fact. They get all the attention in a forum like this. Ubuntu is what gets all the people, though.

You have a statistical point of view that doesn't go into detail enough: yes, Debian, Ubuntu, Mint are mainstream distros and use ext by default. The vast majority of their users are also mainstream users and would never approach declarative distros, which are alien to them.

Those who choose going declarative instead are people with operations knowledge, who understand the value of a system ready to be built, modified, and rebuilt with minimal effort thanks to the IaC built into the OS, who understand the value of their data and therefore babysit them properly. The average user of Debian, Ubuntu, Mint today doesn't even have a backup, uses someone else's cloud. If they run experiments, they waste storage with Docker, or use manually managed VPSs; they don't own a complete infrastructure, let alone a modern one.

So thinking about them for Guix means never letting it take off, because those users will never be Guix users. ZFS is the opposite of complicated; it's what you need to live comfortably when you know how to use it, which unfortunately isn't mainstream, and declarative distros do the same.

NixOS succeeds despite the indigestible Nix language because it offers what's needed to be comfortable to those who know. Guix remains niche not because of GNU philosophy but because it doesn't do the same, not offering what those coming from operations are looking for and they are the most potential realist target users.

I believe you stated the problem in a way that its unsolvable. Charge your customers money, so you can work for them. I'm not nearly as certain as you are that Netscape failed because it was charging money. Netscape just stopped updating for multiple years at the height of the browser wars.

For Firefox in particular, I would 100% be willing to pay for it. Individuals like me who will pay are rare, but companies that will pay aren't. I think the answer for modern Mozilla is a Red Hat style model. Charge a reasonable amount of money. Accept that someone is going to immediately create a downstream fork. Don't fight that fork, just ignore it. Let the fork figure out its own future around the online services a modern browser wants to provide.

Then, lean hard into the enterprise world. Figure out what enterprise customers want. The answer to that is always for things to never, ever change and the ability to tightly control their users. That isn't fun code to write, but its profitable and doesn't run counter to Mozilla's mission. That keeps Mozilla stable and financially independent.

Mozilla will maintain lots of influence to push forward their mission, because hopefully their enterprise customer base is big, but also they are the ones actually doing the work to make the downstream fork possible.

Firefox is reportedly rolling out an enterprise option in 2026 so we'll see how that goes.

> I believe you stated the problem in a way that its unsolvable.

I think you misunderstood me. I asked a question because the answer is far from obvious. If the solution to this problem was obvious, we wouldn't be having the same discussion on HN every 6 months when a new press release from Mozilla comes out.

I am very much interested by what people think the solution should be. Now, you mentioned Enterprise customers which is interesting because usually what I have read on this sort of threads was that Mozilla had made many mistakes (I agree), Mozilla should change their ways by removing this feature or adding this feature but almost everyone conveniently forgets that at the end of the day someone has to pay for all this stuff.

> Charge your customers money, so you can work for them.

Which is what I mentioned in my comment. Start charging people. The problem is how do you convince the general public to use Firefox instead of Chrome or Edge, especially is you need to pay for the software?

If privacy was a selling point, then Meta would have closed shop many years ago.

> I'm not nearly as certain as you are that Netscape failed because it was charging money. Netscape just stopped updating for multiple years at the height of the browser wars.

It doesnt matter because we will never know. The reality is that people expect to browse the internet for free. Asking them for cash has never been done at this scale.

If Mozilla was to start charging money tomorrow, you would find that many people would object to that and most people would simply move to Chrome because why not?

> Then, lean hard into the enterprise world. Figure out what enterprise customers want. The answer to that is always for things to never, ever change and the ability to tightly control their users. That isn't fun code to write, but its profitable and doesn't run counter to Mozilla's mission. That keeps Mozilla stable and financially independent.

I understand the comparison with Red hat but I am doubtful that this model will work. Red Hat helps companies ship stuff, it makes people more productive, it increases the bottom line. What would a paid version of Firefox do that makes people more productive or makes companies money that they couldn't get from Chrome? I am genuinely asking because again, it's mot very clear to me.

> Mozilla will maintain lots of influence to push forward their mission, because hopefully their enterprise customer base is big, but also they are the ones actually doing the work to make the downstream fork possible.

That is big assumption that has not been proven at this time. I think that making any sort of plans based on hypothetical paid version is highly speculative.

I wouldn't mix OAuth and OIDC up when thinking about this. OAuth is a chaotic ecosystem, but OIDC is fairly well standardized.

OIDC actually does have a discovery mechanism standardized to convert an email address into an authoritative issuer. Then, it has a dynamic registration mechanism standardized so that an application could register to new issuers automatically. Those standards could absolutely be improved, but they already exist.

The problem is that no one that mattered implemented them.

If you want to get anywhere with something like this, you need buy-in from the big email providers(Google, Microsoft, Yahoo, and Apple) and the big enterprise single sign on providers(Ping, OneIdentity, and Okta). All of those companies already do OIDC fairly well. If they wanted this feature to exist, it already would.

Instead, it seems like big tech is all-in on passkeys instead of fixing single sign on.