So OpenAI is acquiring Astral

MP 164: Will you keep using uv? I sure will, until there's a more specific reason not to.

The Python world was all abuzz recently after Astral announced they were being acquired by OpenAI. If you're unfamiliar with Astral, they're the team behind uv. This acquisition has a lot of people talking about whether or not it's reasonable to keep using uv. I'm ready to adopt a different tool when I need to, but I'm in no rush to move away from using uv just because of this announcement.

A brief timeline

To put uv's development in context, it's helpful to understand a brief timeline of Python packaging tools:

• 2008: pip was first released. This resulted in a more consistent and user-friendly process for installing Python packages.
• 2018: Poetry was first released. The 1.0.0 release came in 2019.
• 2020: PDM was first released. The 1.0.0 release came in early 2021.
• 2024: uv was first released.

I'm leaving some important package managers out of this timeline, because I just want to make the point that uv is really young as far as Python package managers go.

I like uv because it's fast, but also because it does more than just install Python packages:

• Installs as many different versions of Python as you need, and makes it easy to keep each interpreter up to date.
• Manages virtual environments.
• Lets you run Python projects without thinking about where or how they're installed. It does the messy work in the background, which often times is good enough.

That last phrase, "good enough", is part of why uv has done so well. Trying to replicate all of pip's functionality is a daunting task. Python is a glue language, and that means a package manager that has to handle all possible use cases has a lot of edge cases. One of the decisions the uv team made was to decide which edge cases it would not prioritize. They've focused on articulating and supporting modern Python workflows. When you have a strong team with a clear vision, a blank slate, and can choose which workflows to support, you can develop a faster tool. That's what we have with uv.

Why is OpenAI's acquisition concerning?

Astral accepted venture capital funds to support their initial work, which meant they needed to sell or become profitable at some point. People have always known an acquisition was possible, and many people started adopting uv-based workflows reluctantly because of that.

The acquisition itself isn't the issue; the main issue for most people is the uncertainty around what will happen with uv:

• Will OpenAI support the ongoing development of a fully open Python package management tool, or will they decide that's not profitable or important enough for them?
• Will OpenAI turn uv into a more proprietary tool?
• Will uv incorporate AI to implement some of its functionality?

These are really important questions. One of the reasons uv works so well is because Astral has spent large sums of money paying people to work full time on Python package management. The tool works well today, but it's not finished, and it will never be finished. It has certainly shaped the landscape of Python packaging tools, but it needs ongoing development and maintenance. Soon, decisions about how much to put into those tasks will be made by OpenAI, not Astral.

When a for-profit company controls an ecosystem tool like uv, it's tempting for that company to use the tool to steer people towards its profit-making products. Consider VS Code, which is based on an open source IDE. The version of VS Code that most people install comes from binaries produced by Microsoft. Microsoft takes the open IDE, and packages its own proprietary add ons when building VS Code. Over the past couple years, VS Code has included "features" that constantly try to get people to use their paid AI tools. I recently switched to VS Codium, which is just the open source IDE VS code is based on, without any of the Microsoft-specific features. Not everyone can do this, because some VS Code users rely on proprietary integrations that Microsoft adds in. I wonder if we're going to see an open core of uv, alongside an OpenAI-packaged version that tries to steer people toward their paid offerings.

uv is great because it's a fast, deterministic package management tool. It looks at the packages you're trying to install, examines the relevant aspects of your development environment, and figures out the correct dependencies to install. Most of the time, it does this quite well and quite fast. One way to make uv worse after the acquisition would be to replace some of its dependency resolution logic with LLM magic. It feels ridiculous to type out that thought, but how many products have we seen degrade in quality over the past several years because a company decided to shove AI into something that was already working well?

A mountain story

I lived in a small town in southeast Alaska for a long time, and I loved it because we lived right on the edge of the wilderness. Southeast Alaska is full of steep mountains that rise up almost straight out of the ocean. There aren't a lot of long ridge walks, because so many ridges are broken up by cliffs of varying sizes. You can pencil out a long off-trail hike through the mountains on a map, and then get turned back a couple miles into the hike by a 15-foot cliff band that's big enough to stop you, but small enough to not show up on a lot of maps. But sometimes you'd get up to that cliff band and find a small, mostly hidden path that would let you make your way through the cliff band and keep going.

There were so many beautiful ridges and so many small cliffs, that I ended up making a helpful rule for myself. When I saw a cliff band up ahead on a hike, I wouldn't turn around right away. I made myself keep going forward until I literally couldn't take another step. Often times what looked like an impassable cliff, even up close, had enough footholds and brush to hold onto, and broken places to stand on, that you could pass. I had many gorgeous hikes that seemed impossible from a ways off, but worked well if you just kept taking each step that appeared in front of you.

Abandoning uv?

I thought of this rule when I heard so many people say they were going to stop using uv immediately after the acquisition announcement. I'm going to keep using uv until there's a specific reason not to. I could replace my uv-based workflows with pip, Poetry, PDM, or any number of other choices at the moment. But I don't want to go back to those tools. uv works for me today, and will almost certainly work for me tomorrow. I'm guessing it will work for me next month. Will it work for me next year? I don't know. But if I actually need to move away from uv, I'd like to do that when we see how this all plays out.

Forking uv?

And that brings us to the topic of forks. People immediately starting talking about the possibility of forking uv if OpenAI enshittifies it. Of course forking is an option, but we have to keep in mind that millions of dollars have gone into developing and maintaining uv and other Astral tools that integrate with uv. We can fork the project, but no one can maintain a tool like this by themselves. It's possible to build a package manager as a volunteer-led project, just like all these other tools have shown. But that's a much different endeavor than what Astral has been doing for the last couple years.

If OpenAI turns out not to be good stewards of uv and the other tools Astral was building, I'm quite curious to see what new open tools will emerge from all this. That might be a fork of uv, or it might be another blank-slate tool that builds on what uv has shown is possible.

Closing thoughts

I'm definitely not excited to see Astral acquired by OpenAI. Astral was working on a private package index service, which they were calling pyx. The idea is that while many people install all the Python packages they need from PyPI, a lot of businesses need to build their own private package index to install from. That lets the company choose exactly which packages and versions to allow onto their systems. For small teams, this isn't too difficult to manage. But for large companies using complex combinations of packages, that's a lot of difficult work that they're happy to pay for.

I was hoping to see pyx grow to become profitable enough to support Astral's open source work. Maintaining a private package index service aligns well with maintaining a fully open package management tool. Astral could have built features into uv that make it work better with their private package index, and with PyPI as well. That alignment is much less clear under OpenAI's direction.

I think pyx was likely to be profitable at some point, because Astral had already demonstrated how good they are at building fast, well-articulated tools. But was it going to be profitable enough? And how long would it take to become profitable? My guess is that OpenAI dangled a pile of cash in front of Astral and said they can have all that money now if they want it, without waiting to see if the pyx idea worked out. And we don't know how much pressure Astral's early investors were putting on them to accept cash now instead of focusing on long-term sustainability, but we do have a pretty good understanding of how VC funding tends to work. :/

I'm going to keep using uv until there's a specific reason not to, and keep watching what happens in the larger Python package management ecosystem. When uv incorporates some behaviors that are unacceptable to me, I'm going to be ready to move to something else. But that tool may not even exist yet, so I'm not in any rush to move away from uv.