Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • > Additionally, when a critical package has no one maintaining it, Akrites will stand as the maintainer of last resort so a fix can still reach everyone in a timely fashion.

    Ambitious and interesting. I wonder how long this will last and on whose dime and time? Akrites employs no engineers, so who will make the fixes and who'll pay them?

  • Yeah, very commendable. Now I just wish the closed-source software that have lost support could similarly be supported this way, with the help from AI, so we don't have to throw away that many hardwares when their software can no longer be updated.
  • I'd be interested in 1) what makes a package "critical" 2) how do you take ownership if the original author is unreachable or not cooperating? Are you going to fork it and somehow make everyone switch to your fork, even on older LTS systems?
  • Who they employ then? AI?
  • Nice name, "Akrites".

    Probably not as impressive to a non-Greek, but to a Greek person it creates very strong imagery.

  • To UK oldies it probably reminds them of the sitcom Open All Hours with Ronnie Barker.
  • A more recent example would be Mark Carney's Davos speech [1], specifically "middle powers must act together because if we're not at the table, we're on the menu."

    [1] https://en.wikipedia.org/wiki/Mark_Carney%27s_Davos_speech

  • To save others a search:

    > The akritai (singular akrites) is a term used in the Byzantine Empire in the 9th–11th centuries to denote the frontier soldiers guarding the Empire's eastern border, facing the Muslim states of the Middle East. (Wikipedia)

    Akron means edge or border, so "frontiersman" or "those of the border".

    EDIT: Commenters seem upset about the Muslim part, I didn’t mean to imply anything, you cannot just copy-paste contemporary disputes and prejudices a thousand years ago. In the historical context it’s just like most borders between different civilizations. The point is that they were a collective organization getting together to defend their land.

  • I yearn for the day I see a headline like "We All Depend on Open Source. We Will Fund It Together"
  • yea this headline is pretty disgusting
  • Many of these bigger companies are "funding open source" by paying their employees to participate. Look at all of the corporate email addresses on the LKML for instance...
  • It seems to me as someone who wasn't paying attention to open source 10 or 20 years ago that its no longer a real community effort. Projects are maintained by their maintainers and get very little from the community. Commercial open source gets even less from the community. The only real value generated is corporate supported projects sharing with corporate supported projects. The average person is happy because they can also use these projects but ultimately they do nothing with it. The only people benefiting is the corporations that use this to build their products.

    I dont know if this is a good thing or not. On paper it seems fine but there is something that feels wrong about it and I dont know exactly what.

  • There never was "a community". The vast majority of all open source software is written by people paid by some corporation to do so.
  • > It seems to me as someone who wasn't paying attention to open source 10 or 20 years ago that its no longer a real community effort.

    I would disagree with this, it's the same amount of community effort as it's always been. Big projects have big governance, and receive lots of patches. Smaller projects receive fewer patches. The community generally happens in Discord or IRC or on mailing lists, but it definitely exists.

    The real threat to "community effort" are drive-by low-effort LLM-generated Pull requests that decrease the signal-to-noise ratio by a lot and make managing open source projects such a slog

  • The most important information is this:

    > participants will contribute engineering resources

    If it works out as planned, we will see. Apart from this, I am not overwhelmed by the claim of this project. It favors centralization and corporate circles, exactly the opposite of what the hacker ethics promotes for good reasons.

  • You can even shorten that. This is some corporate hollo-bollers takes-your-time-and-gives-nothing-in-return fakery-roo.

    > exactly the opposite of what the hacker ethics promotes for good reasons.

    Yup. Seems kind of like those zombie plants in the movie "Invasion of the Body Snatchers" (the first remake; though the original is also great, but it was more about communism as threat, whereas the first remake added a bit of alien horror motifes).

  • Doesn't seem very inclusive. Seems to be another layer to centralize the inbound vulns, gather intelligence and handle them in secret.

    It may also turn into another source of pressure. Maybe they manage to sort out the real vulns, but then they come in as high priority to the maintainers.

    Many maintainers are already exhausted from their normal work, sans AI noise. Even if they supply fixes, it still requires review.

    In best case they could reduce noise but the work is still there. The industry needs to generally fund OS projects to give them the agency to handle it on their own. That's is likely best for quality. If there is still need to filter AI noise then they can add that, but not as a secret opaque thing that controls it all.

  • > We are joined by Amazon Web Services ...

    There goes all the credibility of this post

  • This reads as centralization and control effort. It will only provide the power to control opensource to whoever Akrites is (with the major bigtech including Google).

    Thank you very much, but I remember what Google is doing with Android this September (closing third party installs using .apk).

  • This is my concern as well. If critical open source packages become dependent on these corporations for "secure" releases, does that enable them to force ID verification into packages, for example? Related, but most of the smart folk I know think Open Source AI means Anthropic and OpenAI are financially impossible. A lot of the companies signed onto this are heavily, heavily leveraged by those two, and have significant incentive to disrupt Open Source AI before all their customers get sticker shock. I've been waiting to see what their move would be, and this might be part of it.
  • Defending open source should begin with real, tangible support for both the projects and its developers. Not just words.

    With my OpenBSD developer hat on, getting new hardware in the hands of developers is really important, many of us are hacking on 5-10 year old thinkpads that need replacing.

    https://www.openbsd.org/want.html

    The OpenBSD foundation is ~50% away from its fundraising goal for 2026!

    https://www.openbsdfoundation.org/campaign2026.html

  • I wanted to buy a couple of ubikeys to secure my gpg key (which can be used to upload to debian) and seems if I want them it's on me, yay!
  • Also in addition to funding the open source projects you use, if you can, please consider directly supporting individual contributors/developers personally who work on those projects, many are volunteers and even a small monthly contribution could mean the difference.

    https://brynet.ca/wallofpizza.html

  • > We are joined by Amazon Web Services, Anthropic, Chainguard, Cisco, Citi, Endor Labs, Ericsson, Google, IBM, JPMorganChase, Microsoft and GitHub, NVIDIA, OpenAI, RapidFort, Red Hat, Rust Foundation, Sonatype, Vodafone, and Zscaler

    Many of the names on the list makes the initiative rather suspect. Companies who do a lot to undermine free and open-source software, who hide critical software behind their walls, preventing both its scrutiny and its adaptation and improvement, and two of the LLM giants - they'll "defend open source"? I don't know about that.

    > Akrites gives critical infrastructure stakeholders a confidential, structured place to coordinate vulnerability discovery, remediation, and disclosure across the open source projects they depend on

    So, a bunch of large corporations - some of who are known to be in bed with the US government - will share vulnerabilities among themselves, out of the public eye? Fishy.

  • It won't be out of the public eye if it is part of Linux Foundation, it will be open.
  • That's just your typical list that makes up the Linux foundation.

    It might not be the idealistic flavour of open source you prefer, but it's the flavour of open source that's actively in use in most tech companies, and that also forms the makeup of most corporate open source participation (e.g. also the top corporate Linux contributors).

  • Not...really? It's pretty normal. Tech companies share intelligence and knowledge all the time -- there are a lot of birds of a feather and consortium groups out there.

    Since a lot of places are close in proximity, companies sometimes run private fiber lines and such to let peers download updates without competing with the entire world lol.

    Everyone's fighting the same fight. Sharing and collaborating are normal things.

  • > All members must be current Linux Foundation members and sign the participation agreement and NDA.

    Just another opaque and exclusive subproject of the Linux Foundation.

  • Yeah, a bunch of the worst free riders and malicious consumers all in one place.

    All they're really missing is Oracle and Bambu Lab.

  • Nonsensical corporate posturing.

    "Microsoft will contribute expertise, resources, and AI technologies to help responsibly identify and fix vulnerabilities"

    As a reminder, Microsoft runs NPM and GitHub. Microsoft has access to the best AI models and massive data centers. Despite that, their own products are rapidly getting worse at security and their services are central hubs through which various exploits are propagated. They are not making things better, they are actively and rapidly making things worse.

    --

    For a great example of how Microsoft deals with security issues within their own Open-Source projects, I recommend reading this GitHub thread:

    https://github.com/dotnet/efcore/issues/38257

    EF core currently distributes a version of SQLite that has a severe vulnerability. The issue was discovered over a year ago. It was fixed by SQLite within one week. EF core didn't mark their driver as vulnerable until a user recently reported it, got bounced around and argued with developers. The current stable version of .NET core will only get a fix in roughly two months.