How does an operating system that isn't proprietary or powered by the Linux kernel manage to run Docker, you ask? Well, it would need features like namespaces and cgroups.
That's exactly what Vinix did, adding its own implementations of those plus overlayfs and seccomp, allowing the stock Alpine Linux Docker engine to run on ARM64.
It also runs QEMU 9.1.2, which can boot a second Vinix inside a window of the first, and for gaming, it can run DOOM, a DOOM 3 demo, Gothic II's demo via OpenGothic, and Minecraft Java Edition.
There are still some limitations.
For instance, the Docker support lacks bridge networking and iptables rules, and QEMU runs on software emulation for now. Minecraft runs in interpreter mode on one CPU core, and DOOM 3 manages about 13 FPS under software rendering.
🚧
This is early-stage software that is not meant to be used daily or in production environments.
Yet another OS?
Vinix exists to give MacBooks a fast, minimal, open source OS, with the project's motivation being tied to macOS getting slower and bloated with every passing release. They are initially targeting Apple Silicon devices to eventually cover the whole M-series lineup, though only the M1 is supported right now.
While Linux users have little reason to switch to it, Vinix aims for a setup without systemd and a kernel small enough for one person to read through.
Beyond that, nothing runs in the background unless you start it, and the system sticks to a single init system, desktop, package manager, and binary format. The kernel handles memory manually instead of using a garbage collector, so a cleanup pass can't interrupt a system call or the compositor.
All of it runs on a V programming language foundation, which was picked for its fast compiles and small, readable design. The project doubles as a testbed for bare metal programming in V too!
The security model of the OS is modeled after OpenBSD, with pledge and unveil available, though apps must opt in, and user memory can't be both writable and executable by default. Verifying the bootloader, kernel, and root filesystem isn't supported yet.
It runs Linux apps
At its core, Vinix is a monolithic kernel booted through Limine, with its drivers built into the image. Most of it is V, alongside some C and assembly.
It features a native desktop built with V UI2 that renders through the framebuffer, with X.org and Hyprland sessions as options on ARM64. The developers claim that the OS takes up 50 MB of RAM after boot and roughly 1 GB of disk once installed.
Alpine Linux, the distro behind that Docker engine from earlier, is lightweight and security-focused, and it's built around musl and BusyBox. Vinix targets its aarch64 packages.
Thanks to that, Vinix is able to run Linux apps because it answers the system calls they make, plus the ELF format and musl behavior they rely on, and those binaries run natively, without a VM or an emulator.
New applications can be installed with pkg, a command-line tool that pulls packages from Alpine's aarch64 repositories. Apps like Chromium, GIMP, Sublime Text, and Gnumeric are known to work, as is Wine, the widely adopted compatibility layer.
The catch is that this is limited to ARM64 and selected packages. Software that relies on a Linux kernel feature Vinix doesn't have yet may not run properly.
Additionally, support for the M3, M4, and M5 is coming soon, while GPU drivers are still a work in progress.
Vinix's history spans many years, with the first commits on GitHub dating back to March 2021 and the original kernel core being the work of Mintsuki, the creator of Limine.
Development then paused for around two years before Alexander Medvednikov, the author of V, took over as maintainer.
Mintsuki's core covered the physical and virtual memory managers and the scheduler, but since the handover, Vinix has gained storage, networking, input, and graphics support, along with a Unix-style userspace and the Alpine compatibility we saw earlier.
Get Vinix
You will find that the official website offers a .dmg installer file for M1 Macs, whereas the project repository hosts two distinct ISOs, one for ARM64 (targeted at QEMU and VirtualBox on Apple Silicon Macs) and the other for x86_64 (targeted at Intel and AMD systems).
If you want to test it on a virtual machine, the requirements are quite modest. Vinix needs at least 4 GB of memory and 4 GB or more storage space. Building from source is also an option.
Since 2022, Google's Open Source Software Vulnerability Reward Program (OSS VRP) has been the path for outside researchers to get paid for reporting security flaws in the company's open source code, including projects like Flutter, Angular, Go, and Fuchsia.
With an announcement on X, they have now decided to discontinue the product-facing side of it.
They are calling the change temporary, while supply chain reports remain open and anything submitted before October 1 stays unaffected.
What's closed, what's not?
📢 PSA for open-source bug hunters
We are temporarily no longer accepting OSS VRP product vulnerability submissions. This does not impact OSS VRP supply chain reports, or any outstanding reports. As an alternative, we encourage you to find impact across our other VRP programs…
— Google VRP (Google Bug Hunters) (@GoogleVRP) October 1, 2026
Product vulnerabilities are bugs in the projects themselves, like a failing HTML sanitizer, memory corruption issues in file format parsers, or insecure code examples in documentation.
The updated rules do not limit the change to a specific project tier, as they just won't be accepting any reports related to this.
Supply chain reports, on the other hand, cover vulnerabilities in how the software is built and shipped. Exposed package manager credentials used to publish build artifacts is one case the rules page lists. It remains unaffected by this change.
There's also an exception for some Google Cloud repositories. If a bug there affects a Cloud product, Google may still accept the report, but through its Cloud VRP.
Why did it come to this?
Back in March, a post on the Bug Hunters blog from Google engineers said AI-generated reports were flooding the program. Some were serving up hallucinated information, while others were flagging legit coding errors that had little to no impact on the security posture of the targeted project.
Google's first response was to raise the bar on memory corruption reports for its two top project tiers. Researchers had to either reproduce the bug through an existing OSS-Fuzz fuzz target or point to a patch that maintainers had already merged.
An update to the same post the following month went further. The standard and low-priority tiers, OT2 and OT3, stopped offering rewards or credit for product vulnerabilities and other security issues. The top supply chain reward for OT2 projects also fell to $3,133.70.
Supply chain reports still pay, from $500 on OT2 projects up to $31,337 on flagship ones.
As an alternative, Google points to the Patch Rewards Program, which pays between $100 and $15,000, though only for patches that have stayed in a project for a month without being reverted.
An open question
Google has not said when or in what form product vulnerability reports will return. Their announcement only promises an update in the first quarter of 2027 while they continue reworking that part of the program.
There's also a loose end. At the time of writing, the OSS VRP page still lists reward ranges for product vulnerabilities, up to $7,500. Though, as you saw earlier, the rules page for it has already been updated, so it shouldn't be long before this is addressed.
Lightwell is Red Hat and IBM's response to a specific problem in enterprise open source security. Vulnerabilities sit in production library versions that upstream maintainers haven't patched and, in some cases, won't.
More than 90% of enterprise application code traces back to open source or third-party libraries, per figures Red Hat cites, and a typical enterprise codebase carries over 500 known vulnerabilities at any given time.
They say that attacks on known vulnerabilities arrive, on average, a week before any patch exists.
Lightwell's approach is to bypass that timeline. Rather than waiting for upstream maintainers to push fixes to the library versions enterprises are actually running, it backports those fixes directly, delivering them through secure package repositories.
Red Hat reached out recently to share how far it has come.
400 down, more to come
To date, Lightwell has already managed to clear 400 previously unknown vulnerabilities across foundational Java libraries, going beyond reported CVEs and contributing fixes upstream in line with responsible disclosure protocols.
The primary target so far has been organizations running Java environments with pinned dependency versions that can't be safely updated. Lightwell patches those in place, leaving the pinned version intact.
Coverage is also set to expand beyond Java, with Python, JavaScript, and .NET on the roadmap. Each will follow the same approach, with fixes backported to the versions already in production and applicable patches being contributed upstream.
The Clearinghouse opens up
Then there's Clearinghouse Premier, which has so far operated on restrictive terms. Before today, it was reserved for a pre-selected group of organizations in critical infrastructure sectors.
That restriction is now lifted, as it has reached general availability, which means any enterprise can sign up for Clearinghouse directly without waiting on an infrastructure designation to clear access.
You see, Lightwell runs across two access tiers. The Lightwell Network, which reached general availability in July as a self-service subscription open to any organization. It provides access to the backported patches and their compliance documentation.
What Clearinghouse Premier offers is more tailored. Organizations can specify which vulnerabilities matter most to their environment, get early notice before issues go public, and know exactly when fixes will arrive.
As a whole, Lightwell sits within IBM and Red Hat's $5 billion commitment to open source security, with both companies pointing to AI-assisted tooling raising the stakes on older, unpatched open source dependencies.
That stance is further strengthened by Gunnar Hellekson, Vice President and General Manager for Lightwell at Red Hat, who stated that:
AI agents shifted the threat landscape overnight, exploiting old dependencies at machine speed. They do not care if a codebase is ten years old or otherwise considered stable, because one small crack is all it takes to chain an attack together.
If you are interested in what's being offered, a closer look before committing is possible via Red Hat's technical demo, which will walk you through the patching workflow.
The globally recognized tech and engineering company has quietly shut down the OpenRadioss project at the start of this month, keeping the GitHub page around but completely removing the repository.
I sound complainy because usually when an open project is discontinued, the maintainers put it into a read-only, public archive state, which allows other developers to learn and fork off it.
OpenRadioss was the open source release of Radioss, a finite element solver Altair Engineering developed for crash testing, blast response, impact analysis, and other structure loading scenarios.
They had released it in September 2022, drawing in a multinational community of researchers, software developers, and industry contributors who extended the solver and built upon the code.
Siemens, which acquired Altair last year, kept the repo and its contents publicly available for more than a year after the acquisition before abruptly deleting it and redirecting people to its transition page for Simcenter Radioss.
A fork appears
Brian Clemens, the co-founder of Rocky Linux has already got an OpenRadioss fork up and running, which carries the full OpenRadioss commit history, ships under the same GNU AGPLv3 license, and is hosted on GitHub.
It's called OpenCourant, named after mathematician Richard Courant and the Courant-Friedrichs-Lewy (CFL) condition, a stability criterion central to solvers like this one.
In fact, this fork owes its existence to the AGPL. You see, Siemens is legally within its rights to take down the repository, but the license applying to every commit gave anyone the right to fork, distribute, and build on the code.
It's just sad to see how abruptly the takedown was carried out; makes you think they didn't want people to get a heads-up.
Also worth noting is that OpenCourant is an independent community project, and it is actively looking for past OpenRadioss contributors to pitch in.
What's already shipping?
Initially, the upstream build pipeline that depended on proprietary Siemens infrastructure could not be transferred. That was rebuilt from scratch, and the results appear promising.
Just days since its inception, the project is already distributing Linux and Windows x86_64 packages.
And before that, a closed-source hm_readerinput-reader binary that was never committed to the git history disappeared along with the upstream OpenRadioss repository.
Thankfully, an unnamed community member who had kept a copy came forward, the OpenCourant team independently verified it, and it now ships in every build. Though they are still looking for specific release archives to start work on ARM64 support and improve current platform compatibility.
If you are interested in OpenCourant, then its package options include the Starter and Engine offerings in single and double precision, SMP builds, and converters for animation files and time history data.
If you get lost, the INSTALL.md file can be a good resource, though keep in mind it is still the OpenRadioss version, as the OpenCourant team has yet to update it to reflect the new project.
You already know that Canonical has been selectively replacing Ubuntu's C-based system components with Rust-written equivalents that don't compromise in terms of functionality, most of the time.
Now it looks like the distro's OpenPGP implementation is next, with Sequoia PGP coming preinstalled in Ubuntu 26.10. Canonical wants it to eventually replace GnuPG as the default toolchain, though that switch has not happened yet.
What's OpenPGP?
Before getting into Sequoia, it helps to know what OpenPGP actually is. It's not a tool but rather a widely adopted standard.
Phil Zimmermann created the original PGP in 1991, and the IETF now maintains the open version of that work. The specification defines how software should encrypt, decrypt, sign, and verify data so that any two implementations following it can work with each other's data.
On Linux, GnuPG has been the dominant implementation of that standard. Written in C, it implements RFC 4880 and offers the gpg and gpgv commands on the platform. These handle everything from encryption and key management to standalone signature verification.
Sequoia PGP is different
It was started in 2017 by three former GnuPG developers who chose to build a new OpenPGP implementation in Rust rather than keep evolving GnuPG’s existing codebase.
Sequoia PGP is designed as a library that other software can use directly, rather than a standalone command-line tool. sq sits on top of that for encryption, decryption, signing, and key management, and sqv handles signature verification, filling in for gpg and gpgv in GnuPG.
Sequoia also implements RFC 9580, the 2024 revision of the OpenPGP standard, whereas GnuPG has continued from the RFC 4880 branch, pursuing its own newer extensions and the LibrePGP specification rather than adopting RFC 9580 as its primary standard.
What's already in?
Ubuntu 26.10 "Stonking Stingray" already pulls in Sequoia PGP from the main archive (look under rust-sequoia-xx) as part of the default installation. I ran sq and sqv on a development build of 26.10, and both were working correctly.
Here, sq acts as the main interface for encryption, decryption, signing, and key management, while sqv handles signature verification. And typing gpg and gpgv still routes to GnuPG, so these two OpenPGP implementations sit alongside each other.
If Sequoia PGP is made the default, you can expect those commands and other GnuPG ones to route to Sequoia instead, similar to how we saw with sudo-rs.
Still a long way to go
The release notes for Ubuntu 26.10 and a recent announcement clearly mention that Sequoia PGP becoming Ubuntu's default OpenPGP toolchain is a future goal, not something that's already the default experience.
The coreutils transition started in 2025 and only reached 100% with 26.10. The sudo-rs switch was shown off well in advance before it became the default. Each of these components had to earn their place over multiple release cycles before anything changed for users.
Sequoia PGP is at the start of that process. Landing in the main archive is the first milestone. Whether it eventually replaces GnuPG as the default remains to be seen.
Canonical has not shared a specific inclusion timeline. Given how carefully they have moved on every other Rust transition so far, that caution is unlikely to disappear for something as foundational as OpenPGP.
A few months back, I reviewed the TerraMaster D1 SSD Plus and liked it for what it offered. A sturdy box that gives a second life to an NVMe SSD lying around (rarity these days).
Now I have the ORICO X50 on my desk, which does the same job but promises twice the bandwidth with Thunderbolt 5.
I ran the similar set of benchmarks on it on Ubuntu, and I have the numbers to share.
Here's a quick summary of my experience with the device.
✅ Slim, good-looking aluminum body that's easy to carry ✅ Comes with an 80Gbps cable in the box ✅ Works out of the box on Linux, with full NVMe SMART data ✅ Stayed in the 60s °C during a 13-minute sustained write ❎ Only 2280 NVMe SSDs; heatsink SSDs won't fit ❎ Priced well above USB4 enclosures
Here are the hardware specifications for ORICO X50.
Specification
ORICO X50
Interface
Thunderbolt 5 (80Gbps), backward compatible with Thunderbolt 4, Thunderbolt 3 and USB4
Rated speed
Up to 6000 MB/s read, 5800 MB/s write
Supported SSD
M.2 NVMe, 2280 size only (2230 not supported), M Key and B+M Key
Recommended SSD
PCIe Gen4 or Gen5
Max capacity
4TB
Cooling
Fanless, aluminum unibody with micro fins, thermal film and thermal paste
Material
Aluminum alloy
Dimensions
110 × 60 × 18.7 mm
Cable
0.5m USB-C to USB-C, 80Gbps
OS support
Windows, macOS, Linux
Price
$269.99 for the diskless version
ORICO also sells the X50 with a 512GB or 1TB SSD already installed. I got the empty enclosure, which is what most of you would want if you have an SSD to reuse.
Pay attention to the supported SSD list. Like most enclosures of this kind, the X50 doesn't take everything. It's NVMe only, so your old SATA M.2 drive cannot be used, and it's 2280 only, so the tiny 2230 SSD in your stock won't be of much use either.
Also note that on Thunderbolt 4 hosts, the speed is limited to 40Gbps, and on Thunderbolt 3, it will drop even further.
📋
ORICO sent me this device for review. The views expressed are my own.
Design and build
The X50 is noticeably less bulky than the TerraMaster D1 SSD Plus. It's slim enough to slide into a laptop bag pocket. Although it is not as slim as my Sandisk Extreme portable SSD.
The silver aluminum finish looks good, and I think it would fit right into the Apple ecosystem as it matches the aesthetic.
Flip it over and you'll see fins running along the bottom. These increase the surface area for heat dissipation, and judging by my thermal numbers (more on that later), they seem to do their job. There's no fan, so it's completely silent.
Orico X50 bottom view
In the box, you get the enclosure, a fast 80Gbps USB-C cable and thermal paste. No SSD, of course, since I got the diskless version. A good cable matters with devices like these. Good of ORICO to include it in the box.
You can apply the thermal paste directly on the SSD. I did not. I wanted to take the raw numbers in the testing.
SSDs with an attached heatsink, like the Samsung 9100 Pro Heatsink version, won't fit inside the X50. Get the bare version of the SSD if you plan to use it with this enclosure.
The first plug-in experience
For my testing, I used a Crucial P3 Plus 500GB. It's a PCIe Gen4 drive rated at 4700 MB/s read and 1900 MB/s write, and it uses QLC NAND. Keep the QLC part in mind; it matters for the sustained write results.
I tested the X50 on Ubuntu 26.04 with Linux kernel 7.0. It worked out of the box. Plugged it in, and the SSD shows up like any other drive. I formatted it as ext4 and it was mounted automatically. So, no surprises here.
Since it's a Thunderbolt device, it's worth checking with boltctl. It got authorized automatically and showed a 40 Gb/s link (2 lanes × 20 Gb/s). Interestingly, it identifies itself as "DM9002QN" from Shenzhen Dongman Technology rather than ORICO.
Because the X50 tunnels PCIe over Thunderbolt, the drive shows up as a native NVMe device (nvme1n1), not a USB disk. That means nvme smart-log works directly and you get full SMART data, including temperature. No need to fiddle with USB bridge flags in smartctl.
This is definitely a plus for Linux users. With many USB enclosures, getting health data out of the SSD is often hit or miss.
Performance: the numbers and the big caveat
Here's the thing. The X50 is a Thunderbolt 5 device, but I don't have a Thunderbolt 5 machine. My laptop is the ASUS Zenbook S14, which has Thunderbolt 4. So the link was capped at 40Gbps, half of what the X50 is designed for.
📋
These tests are limited by the host device. With a Thunderbolt 4 laptop, you are not seeing what the X50 can do at 80Gbps. Treat my numbers as "what you get with a Thunderbolt 4 or USB4 machine", which, honestly, is what most people have today.
This is often the case with storage benchmarks. The weakest link in the chain, be it the port, the cable or the SSD, decides the speed you see. The ORICO's rated 6000 MB/s needs both a Thunderbolt 5 host and a fast Gen4 or Gen5 SSD.
I used fio for simulated tests, plus a couple of real file copy tests. Here are the results from the first run.
Test
ORICO X50
Sequential read
3878 MB/s
Sequential write
2810 MB/s
Random read (QD32)
1512 MB/s (369K IOPS)
Random write (QD32)
1175 MB/s (287K IOPS)
Random read (QD1)
59 MB/s (14.4K IOPS, 34 µs latency)
Mixed 70% read / 30% write
1483 MB/s
10GB single file copy
11.8 seconds
5000 small files (4KB) copy
17.5 seconds
The sequential read of 3878 MB/s is pretty much the ceiling of a 40Gbps connection. Pay attention to bits and bytes. The enclosure maxed out what my laptop could offer. The sequential write of 2810 MB/s was well above the Crucial's rated 1900 MB/s, thanks to SLC cache handling the burst.
I ran the tests a second time to check consistency. The read numbers were pretty much identical. Random write dropped to 978 MB/s and the 10GB copy took 17.8 seconds instead of 11.8. That's because the SSD's cache probably had not fully recovered from the earlier runs.
Thermal performance during sustained writing
To see how the X50 handles heat, I wrote 250GB in one go. It took a little over 13 minutes.
The speed fell from around 2700 MB/s to about 265 MB/s within the first few seconds and stayed there till the end. Before you blame the ORICO enclosure, this is classic QLC behavior.
Once the SLC cache is full, the Crucial P3 Plus writes at its native QLC speed. In the earlier shorter run with a fresh cache, it held about 2700 MB/s for nearly 19 seconds before falling off.
Let's focus on the temperature. Throughout the 13-minute write, the SSD stayed between 58°C and 68°C, and mostly stayed around 62 to 65°C.
There were no sudden dips in the speed graph that would indicate thermal throttling, at least that's what I would like to think. The fins and the paste seem to be doing their work. The room temperature was around 32°C, I think.
✅
The X50 kept the SSD in the 60 °C range during a 250GB sustained write with no visible throttling. Thermally, it's well built.
ORICO X50 vs TerraMaster D1 SSD Plus
Since I had reviewed the TerraMaster D1 SSD Plus earlier, a comparison was only natural. I ran the same benchmark script on it, on the same Zenbook S14.
The tests are not indentical though because I used a different SSD in each. Crucial P3 Plus 500GB in the ORICO and the WD Blue SN5000 1TB in the TerraMaster. So this is not a pure enclosure vs enclosure comparison. Take the write numbers especially with a pinch of salt.
ORICO X50
TerraMaster D1 SSD Plus
Interface
Thunderbolt 5 (80Gbps)
USB4 (40Gbps)
Price
$269.99 (sale)
~$110
Max capacity
4TB
8TB
Size
Slim (110 × 60 × 18.7 mm)
Bulkier
SSD in my test
Crucial P3 Plus 500GB
WD Blue SN5000 1TB
Sequential read
3878 MB/s
3323 MB/s
Sequential write
2810 MB/s
3202 MB/s
Random read (QD32)
1512 MB/s
1588 MB/s
Random write (QD32)
1175 MB/s
1470 MB/s
Random read (QD1)
59 MB/s
64 MB/s
10GB file copy
11.8 s
6.2 s
5000 small files
17.5 s
17.1 s
Sustained write (250GB)
~265 MB/s after cache
~950 MB/s after cache
Peak SSD temperature
68°C (13+ minutes of writing)
59°C (about 3 minutes of writing)
On a 40Gbps connection, both enclosures are in the same league. The ORICO had the better sequential read, which is the best indicator of what the enclosure itself can push. The TerraMaster won on writes, but that's largely down to the WD SSD having a bigger cache and faster post-cache speed than my QLC Crucial.
Basically, on a Thunderbolt 4 or USB4 laptop, you won't see much practical difference between the two. The ORICO's extra money buys you a slimmer design and headroom for Thunderbolt 5. That also keeps you future proof for the next few years.
Is ORICO X50 worth it?
If you have NVMe SSDs lying around and want to use them as fast external storage, the X50 is a good device. It's slim, looks good, stays cool, and works on Linux without any tinkering. The native NVMe access is a nice touch for those of us who like to check drive health from the terminal.
The 2280 only support is limiting. If you have a 2230 or 2242 SSD from an older laptop or a handheld, you can't use it here. And with no SATA support, older M.2 drives are out of the picture as well.
If you have a Thunderbolt 5 machine, or you are planning to buy one in the next year or two, the X50 is a future-proof pick. Pair it with a fast Gen4 or Gen5 TLC SSD to actually get near the advertised 6000 MB/s.
If some Reddit posts are to be believed, Digital Ocean is ending its Open Source Credits program quietly:
DigitalOcean has decided to sunset the Open Source Credits Program. As part of this change, we are no longer accepting new credit applications or approving credit renewals, extensions, or additional credit requests.
All this is based on a GitHub issue where the maintainers of the Node.js project received an email from Digital Ocean notifying them about the sunset of the Open Source Credits program.
What was the Open Source Credits program?
Digital Ocean is a cloud server infrastructure provider. It ran this "Open Source Credits" program and under this scheme, they gave approved open-source projects cloud credits to cover infrastructure costs. This helped project maintainers run their projects without paying the hosting bill.
For example, Node.js used DigitalOcean infrastructure for its build operations, including virtual servers, storage, snapshots and backups.
For years, Digital Ocean promoted this program and invited projects to apply to this program by sending them a message via opensource@digitalocean.com.
This seems to have changed now.
Sunsetting the Open Source Credits program?
Note that there is no official announcement on DigitalOcean's blog or social media handles.
There is also a Reddit thread, but the OP doesn't mention if they received the email themselves or which open source project they maintained.
I have scanned Reddit, X and some other social media platform but have't picked up any signals from other open source projects, yet.
Node.js is a big project and discussion is real. So, we can safely say that Digital Ocean is indeed working on ending this program.
Projects in the program won't receive new credits. The will have to manage with whatever credits that have been issued so far. After that, either they pay to Digital Ocean or move their projects to some other platform provider.
The mail also mentions that new projects will no longer be accepted in the program and the inbox (opensource@digitalocean.com) dedicated for this task will no longer be monitored. That closes the door for new applicants.
A mutual partnership
Programs such as this are a mutually beneficial arrangement. When DigitalOcean offered credits, these projects spun up their CI runners, their documentation sites, their release mirrors, and their testing environments on DigitalOcean infrastructure.
In return, they mentioned Digital Ocean in the project website and documentation. Thousands of developers learned about DigitalOcean's platform through these projects. Some become paying customers individually, whereas some bring it into the companies they worked for.
Both involved parties get something positive from Open Source Credits like programs.
Digital Ocean has been reducing its free offering
This is not the first time DigitalOcean has trimmed its community-facing programs without a clear announcement.
Earlier this year, the GitHub Student Pack credits were removed from DigitalOcean's offerings too. Students trying to redeem the standard $200 in free credits found they were no longer receiving them. Again, there were no formal announcements (because it is a bad outlook). So all you will find is community questions by confused users.
Digital Ocean offers $100 free credit (our partner link) to every new user. This program still runs today (so far). Not sure how long this will be offered, though.
Node got Digital Ocean support back
In the same GitHub issue, Node developers discussed their exit strategy. It then led to a discussion of removing Digital Ocean from the homepage, README and partners page.
And as soon as that happened, Digita Ocean reached out with olive branch.
Notice the use of "what version 2.0 of the program looks like" line? This is either a coverup strategy or an actual revamp of the existing program that will be more selective about which projects will be allowed in the program.
The GitHub issue was then promptly renamed from "Transitioning off of Digital Ocean" to "Solidify Digital Ocean Partnership".
Other open source projects might not be lucky
Node.js is a big project popular with developers of all kinds. Getting their name and link removed when their competitors, like Vercel, are still mentioned on Node.js homepage is something Digital Ocean could not afford.
But not all open source projects are going to get that kind of happy ending. If the closure of the program is indeed true, the smaller projects are going to think about infrastructure bills and move.
When maintainers are already drowning in AI slop pull requests and bug reports, this is going to put additional strain on the maintainers.
Hopefully, some newer infrastructure providers will come up with similar programs. No harm in thinking positive.
If you are an open source project maintainer who got this Open Source Credits program closure email, please reach out to us.
