More and more plainly, OpenAI and Anthropic are making plays to own (and lease) the "means of production" in software. OK - I'm a pretty happy renter right now.

As they gobble up previously open software stacks, how viable is it that these stacks remain open? It seems perfectly sensible to me that these providers and their users alike have an interest in further centralizing the dev lifecycle - eg, if Claude-Code or Codex are interfaces to cloud devenvs, then the models can get faster feedback cycles against build / test / etc tooling.

But when the tooling authors are employees of one provider or another, you can bet that those providers will be at least a few versions ahead of the public releases of those build tools, and will enjoy local economies of scale in their pipelines that may not be public at all.

https://pypistats.org/packages/uv

Such an outcome would make me wonder regarding the wisdom of "It is better to have love and lost than to have never loved at all."

Note that uv is fast because — yes, Rust, but also because it doesn’t have to handle a lot of legacy that pip does[1], and some smart language independent design choices.

If uv became unavailable, it’d suck but the world would move on.

[1] https://nesbitt.io/2025/12/26/how-uv-got-so-fast.html

Like, the whole point of open source is that this thread is not a thing. The whole point is "if this software is taken on by a malevolent dictator for life, we'll just fork it and keep going with our own thing." Or like if I'm evaluating whether to open-source stuff at a startup, the question is "if this startup fails to get funding and we have to close up shop, do I want the team to still have access to these tools at my next gig?" -- there are other reasons it might be in the company's interests, like getting free feature development or hiring better devs, but that's the main reason it'd be in the employees' best interests to want to contribute to an open-source legacy rather than keep everything proprietary.

Projects - including forks - fail all the time because the leadership/product direction on a project goes missing despite the tech still being viable, which is why people are concerned about these people being locked up inside OpenAI. Successfully forking is much easier said than done.

I'm done pretending this is a "right tools for the right job" kind of thing, there's wrong people in the right job, and they only know python. If no one self-writes code anymore anyway, at least use a language that isn't a clusterfuck of bad design decisions, and has 1 trillion lines of code in the collective memory of people who don't know what a stack is.

Not disputing that it's a great and widely used tool, BTW.

This is not the point of uv or any good package manager. The point is what prevents Python to suck. For a long time package management had been horrible in Python compared what you could see in other languages.

Maybe there needs to be some nonprofit watchdog which helps identify those cases in their early stages and helps bootstrap open forks. I'd fund to a sort of open capture protection savings account if I believed it would help ensure continuity of support from the things I rely on.

- https://pypistats.org/packages/poetry - https://pypistats.org/packages/uv

In the 2024 Python developer survey, 18% of the ecosystem used Poetry. When I opened this manifold question[0], I'm pretty sure uv was about half of Poetry downloads.

Estimating from these numbers, probably about 30% of the ecosystem is using `uv` now. We'll get better numbers when the 2025 Python developer survey is published.

Also see this: https://biggo.com/news/202510140723_uv-overtakes-pip-in-ci-u...

[0]: https://manifold.markets/JeremiahEngland/will-uv-surpass-poe...

Perhaps it never grabbed me as much because I've been running basically everything in Docker for years now, which takes care of Python versioning issues and caches the dependency install steps, so they only take a long time if they've changed. I also like containers for all of the other project setup and environment scaffolding stuff they roll up, e.g. having a consistently working GDAL environment available instantly for a project I haven't worked on in a long time.

https://github.com/direnv/direnv/wiki/Python#uv

If not, do you develop software with source dependencies (go, java, node, rust, python)? If so, how do you handle acquiring those dependencies—by hand or using a tool?

Mostly no, sometimes I give up and still use pip as a separate user.

> If not, do you develop software with source dependencies (go, java, node, rust, python)? If so, how do you handle acquiring those dependencies—by hand or using a tool

I haven't felt the need to use Go, the only Java software I use is in the OS repo. I don't want to use JS software for other reasons. This is one of the reasons why I don't like Rust rewrites. Python dependencies are very often in the OS repo. If there is anything else, I compile it from source and I curse when software doesn't use or adheres to the standard of the GNU build system.

I favor stability and the stripping of unwanted features (e.g. telemetry) by my OS vendor over cutting edge software. If I really need that I install it into /usr/local, that it what this is for after all.

> And let’s say you constrain yourself to your OS package manager. What about the people on different distros? Their package managers are unlikely to have the exact same versions of your deps that your OS has.

This is a reason to select the OS. Software shouldn't require exact versions, but should stick to stable interfaces.

(Source: I'm an Astral employee.)

That's a point of information, not a point of order.

[1]: https://astral.sh/blog/introducing-pyx

People need to be very careful about resisting. OpenAI wants to make everyone unemployed, works with the Pentagon, steals IP, and copyright whistleblowers end up getting killed under mysterious circumstances.

I'm on the fence about cancelling my JetBrains subscription I've had for nearly 10 years now. I just don't use it much. Zed and Claude Code cover all my needs, the only thing I need is a serious DataGrip alternative, but I might just sit down with Claude and build one for myself.

It's not perfect, but it is light-years better than what preceded it.

I jumped ship to it and have not looked back. (So have many of my clients).

It's not there yet, but it's getting there.

https://xkcd.com/2347/

It's so fast in fact that we just added `ty check` to our pre-commit hooks where MyPy previously had runtimes of 150+ seconds _and_ a mess of bugs around their caching.

https://x.com/AprilNEA/status/2034209430158619084

Ironically this type of stuff really makes me doubt their AGI claims, why would they bother with this stuff if they were confident of having AGI within the next few years? They would be focused on replacing entire industries and not even make their models available at any price. Why bother with a PaaS if you think you are going to replace the entire software industry with AGI?

Is this not just the strategy of all platforms. Spy on all customers, see what works for them and copy the most valuable business models. Amazon does that with all kinds of products.

Platforms will just grow to own all the market and hike prices and lower quality, and pay close to nothing to employees. This is why we used to have monopoly regulations before being greedy became a virtue.

1. For the record: the GPL is entirely dependent on copyright.

2. If AI "clean-room" re-implementations are allow to bypass copyright/licenses, the GPL won't protect you.

This is right up there with Meta lawyers claiming that when they torrent it's totally legal but when a single person torrents it's copyright infringement.

Isn't that the same for the obligations under BSD/MIT/Apache? The problem they're trying to address is a different one from the problem of AI copyright washing. It's fair to avoid introducing additional problems while debunking another point.

2. BigCo bus Company A

3a. usually here BigCo should continue to develop Project One as GPLv3, or stop working on it and the community would fork and it and continue working on it as GPLv3

3b. BigCo does a "clean-room" reimplementation of Project One and releases it under proprietary licence. Community can still fork the older version and work on it, but BigCo can continue to develop and sell their "original" version.

patents protect ideas, copyright protects artistic expressions of ideas

Preferring GPL licensed software means that you're immune to a sudden cut off of access so it's always advisable - but it's really important to stay on top of dependencies and be willing to pay the cost if support is withdrawn. So GPL helps but it isn't a full salve.

I'm careful to not rely too heavily on VC funded open source whenever I can avoid it.

All so they could just vacuum it all up and resell it with impunity.

Feel free to prove me wrong by pointing out this massive amount of advocacy from "mega-clouds" that changed people's minds.

The ads, the mailing list posts, social media comments. Anything at all you can trace to "mega-clouds" execs.

So long ago, in fact, that it was five years before their acquisition by Microsoft.

And, sure, djb wasn't actually likely to sue you if you went ahead and distributed modified versions of his software... but no-one else was willing to take that risk, and it ended up killing qmail, djbdns, etc stone dead. His work ended up going to waste as a result.

Agreed with the rest, though. I relied heavily on qmail for about a decade, and learned a lot from the experience, even if it was a little terrifying on occasion!

I mean philosophically and morally, sure, one can take that position ... but copyright law does not work like that, at least not for anything published in the US after 1989 [1].

[1] https://www.copyright.gov/circs/circ03.pdf

The ones pushing for permissive licenses are rather companies like Apple, Android (and to some extent other parts of Google), Microsoft, Oracle. They want to push their proprietary stuff and one way to do that in the face of open source competition is by proprietary extensions.

The FOSS community at large embraced permissive licenses and it had nothing to do with the interests of big corporations.

Like having a system prompt which takes care of the project structure, languages, libraries etc

It's pretty much the first step to replacing devs, which is their current "North Star" (to be changed to the next profession after)

Once they've nailed that, the devs become even more of a tool then they're already are (from the perspective of the enterprise).

The issue that I see is that Nvidia etc. are incentivised to perpetuate that so the open source community gets the table scraps of distills, fine-tunes etc.

Plus, most users don't want to host their own models. Most users don't care that OpenAI, Anthropic and Google have a monopoly on LLMs. ChatGPT is a household name, and most of the big businesses are forcing Copilot and/or Claude onto their employees for "real work."

This is "everyone will have an email server/web server/Diaspora node/lemmy instance/Mastodon server" all over again.

It's probably a trade secret, but what's the actual per-user resource requirement to run the model?

If the open weights models are good, there are people looking to sell commodity access to it, much like a cloud provider selling you compute.

Once we start seeing Open AI and Anthropic getting into the certifications and testing they'll quickly become the gold standard. They won't even need to actually test anyone. People will simply consent to having their chat interactions analyzed.

The models collect more information about us than we could ever imagine because definitionally, those features are unknown unknowns for humans. For ML, the gaps in our thinking carry far richer information about is than our actual vocabularies, topics of interest, or stylometric idiosyncrasies.

What if labor organizes around human work and consumers are willing to pay the premium?

At that point, it's an arms race against the SotA models in order to deepen the resolution and harden the security mechanisms for capturing the human-affirming signals produced during work. Also, lowering the friction around verification.

In that timeline, workers would have to wear devices to monitor their GSR and record themselves on video to track their PPG. Inconvenient, and ultimately probably doomed, but it could extend or renew the horizon for certain kinds of knowledge work.

We could start today, but sweat shops and factories dominate the items on our shelves.

But I’m sure people will draw the line at human made software…/s

As long as they keep the original projects maintained and those aren't just acqui-hires, I think this is almost as good as we can hope for.

(thinking mainly about Bun here as the other one)

Once you’re acquired you have to do what the boss says. That means prioritizing your work to benefit the company. That is often not compatible with true open source.

How frequently do acquired projects seriously maintain their independence? That is rare. They may have more resources but they also have obligations.

And this doesn’t even touch on the whole commodification and box out strategy that so many tech giants have employed.

If AGI becomes available, especially at the local and open-source level, shouldn't all these be democratized - meaning that the AGI can simply roll out the tooling you need.

After all, AGI is what all these companies are chasing.

The ecosystem will be this way for a while, if not the new normal.

Equivalent or better tools will pop up eventually, heck if AI is so fantastic then you could just make one of your own, be the change you want to see in the world, right?

Oh well. They’ll hopefully get options and make millions when the IPO happens. Everyone eventually sells out. Not everyone can be funded by MIT to live the GNU maximalist lifestyle.

Why on earth would agents ever code in as terrible a language as Python when the cost of significantly better languages is essentially free? The only advantage Python ever had was that it was easy to write

Is it? We still need meatspace humans to vet what these AI agents produce. Languages like C++ / Rust etc still require huge cognitive overhead relative to Python & that will not change anytime soon.

Unless the entire global economy can run on agents with minimal human supervision someone still has to grapple with the essential complexity of getting a computer to do useful things. At least with Python that complexity is locked away within the CPython interpreter.

Also an aside, when has a language ever gotten traction based solely on its technical merits? Popularity is driven by ease-of-use, fashion, mindshare, timing etc.

There is also a really good ecosystem of libraries, especially for scientific computing. My experience has been that Claude can write good c++ code, but it's not great about optimization. So, curated Python code can often be faster than an AI's reimplementation of an algorithm in c++.

And as someone who loves Python and has written a lot of it, I tend to agree. It's increasingly clear the way to be productive with AI coding and the way to make it reliable is to make sure AI works within strong guardrails, with testsuites, etc. that combat and corral the inherent indeterminism and problems like prompt injection as much as possible.

Getting help from the language - having the static tooling be as strict and uncompromising as possible, and delegating having to deal with the pain to AI - seems the right way.

If I ask an LLM or agentic AI to build something and don't specify what language to use, I'd wager that it'll choose python most of the time. Casual programmers like academics or students who ask ChatGPT to help them write a function to do X are likely to be using Python already.

I'm not a Python evangelist by any means but to suggest that AI is going to kill Python feels like a major stretch to me.

EDIT: when I say that Python can do anything any other language can do, that's with the adage in mind. Python is the second best language for every task.

Secondly it's non factual. Python's market share grew in 2025[1][2][3]. Probably driven by AI demand.

[0]: even truer for natural languages.

[1]: https://survey.stackoverflow.co/2025/technology#most-popular...

[2]: https://survey.stackoverflow.co/2024/technology#most-popular...

[3]: https://pypl.github.io/PYPL.html

I maintain an open source project funded by the Sovereign Tech Fund. Getting there wasn't easy: the application process is long, the amounts are modest compared to a VC round, and you have to build community trust before any of that becomes possible. But the result is a project that isn't on anyone's exit timeline.

I'm not saying the startup path is without its own difficulties. But structurally, it offloads the costs onto the community that eventually comes to depend on you. By the time those costs come due, the founders have either cashed out or the company is circling the drain, and the users are left holding the bag. What's happening to Astral fits that pattern almost too neatly.

The healthier model, I think, is to build community first and then seek public or nonprofit funding: NLnet, STF, or similar. It's slower and harder, but it doesn't have a built-in betrayal baked into the structure.

Part of what makes this difficult is that public funding for open source infrastructure is still very uneven geographically. I'm based in Korea, and there's essentially nothing here comparable to what European developers can access. I had no choice but to turn to European funds, because there was simply no domestic equivalent. That's a structural problem worth taking seriously. The more countries that leave this entirely to the private sector, the more we end up watching exactly this kind of thing play out.

A lot of great open source comes out of startups because startups are really good at shipping fast and getting distribution (open source is part of this strategy). Users can try the tool immediately, and VC funding can put a lot of talent behind building something great very quickly.

The startup model absolutely creates incentive risk, but that’s true of any project that becomes important while depending on a relatively small set of maintainers or funders.

I’m not sure an acquisition is categorically different from a maintainer eventually moving on or burning out. In all of those cases, users who depend on the project take on some risk. That’s not unique to startups; it’s true of basically any software that becomes important.

There’s no perfect structure for open source here - public funding, nonprofit support, and startups all suck in their own ways.

And on the point you make about public funding being slow: yeah, talented people can’t work full-time on important things unless there’s serious funding behind it. uv got as good as it is because the funding let exceptional people work on it full-time with a level of intensity that public funding usually does not.

I would absolutely love to know more about this if you are willing to share the story?

Most of the companies that spend $$$$ with them can't use public registries for production/production-adjacent workloads due to regulations and, secondarily a desire to mitigate supply chain risk.

Artifactory is a drop-in replacement for every kind of repository they'll need to work with, and it has a nice UI. They also support "pass-through" repositories that mirror the public repositories with the customization options these customers like to have. It also has image/artifact scanning, which cybersecurity teams love to use in their remediation reporting.

It's also relatively easy to spin up and scale. I don't work there, but I had to use Artifactory for a demo I built, and getting it up and running took very little time, even without AI assistance.

Having a private package index gives you a central place where all employees can install from, without having to screen what each person is installing. Also, if I remember right, there are some large AI and ML focused packages that benefit from an index that's tuned to your specific hardware and workflows.

Plus the obvious need for a place to host proprietary internal libraries.

It was because Astral was VC funded.

https://astral.sh/blog/announcing-astral-the-company-behind-...

There seems to be a pervasive believe that the Python tooling and interpreter suck and are slow because the maintainers don’t care, or aren’t capable.

The actual problem is that there isn’t enough money to develop all of these systems properly.

Google says that Astral had 15 team members. Or course, it’s so hard to make these projections. But it wouldn’t shock me if uv and ruff are each individually multi-million dollar pieces of software.

If you’d like to invest a million dollars to improve pip, or work for free for 3 years to do it yourself, I’m not sure if anyone would object.

Either pay for the product, or use stuff that isn't dependent on VC money, this is always how it ends.

Maybe you use non-transitive pure Python dependencies, but it's likely that your tools and dependencies still rely on stuff in Rust or C (e.g.: py-cryptography and Python itself respectively).

As mentioned multiple times, since my experience with Tcl and continuously rewriting stuff in C, I tend to avoid languages that don't come with JIT, or AOT, in the reference tooling.

I tend to work with Java, .NET, node, C++, for application code.

Naturally AI now changes that, still I tend to focus on approaches that are more classical Python with pip, venv, stuff written in C or C++ that is around for years.

Consider ffmpeg. You can donate via https://www.ffmpeg.org/spi.html

How much money do they make from donations? I don't know but "In practice we frequently payed for travel and hardware."

Translation: nothing at all.

If such a fundamental project that is a revenue driver for so many companies, including midas-level rich companies like Google, can't even pay decent salaries for core devs from donations, then open source model doesn't work in terms of funding the work even at the smallest possible levels of "pay a reasonable market rate for devs".

You either get people who just work for free or businesses built around free work by providing something in addition to free software (which is hard to pull off, as we've seen with Bun and Astral and Deno and Node).

There are examples of foundations or other similar entities paying developers, like Linux, SQLite, even Zig.

Maybe the difference is some projects rely on core contributors more because external contributions are more restricted in some way.

But sure, the entire open source model doesn't work, lol

At worst, it's just Anaconda II AI Boogaloo. The ecosystems will evolve and overcome, or will die and different ecosystems rise to meet the need going forward.

I anticipate OpenAI will get bored and ignore Astral's tools. Software entropy will do its thing and we will remember an actively developed uv as the good old days until something similar to cargo gets adopted as part of Python's standard distribution.

https://xcancel.com/gdb

https://xcancel.com/sama/

The only thing that could prevent this is lack of ability to execute, like how Uber wanted to replace drivers with FSD vehicles.

Even if they believe that their systems will eventually tank employment and replace developers rather than augment meant, the fate of Astral doesn't matter at all in that scenario because a) nobody has a job, and b) you can build your own uv replacement for $20.

I hope those two factors mean that if things go really wrong, then the clean(ish) break with all the non standard complex legacy means an easier future for community packaging efforts.

OpenClaw notably was built around Mario Zechner's pi[0]; uv I believe was highly adapted from Armin Ronacher's rye[1], and uses indygreg's python-build-standalone[2] for distributing Python builds (both of which were eventually transferred to Astral).

[0]: https://github.com/badlogic/pi-mono

[1]: https://github.com/astral-sh/rye

[2]: https://github.com/astral-sh/python-build-standalone

In the worst case, Astral will stop developing their tools, someone else will pick them up and will continue polishing them. In the best case, they will just continue as they did until now, and nothing will really change on that front.

Astral is doing good work, but their greatest benefit for the ecosystem so far was showing what's possible and how it's down. Now everyone can take up the quest from here and continue. So any possible harm from here out will be not that deep, at worst we will be missing out on many more cool things they could have built.

We need public investment in open source, in the form of grants, not more private partnerships that somehow always seem to hurt the community.

Every interface kenneth reitz originally designed was fantastic to learn and use. I wish the influx of all these non-pythonistas changing the language over the last 10 years or so would go back and learn from his stuff.

I started using VS Codium, and it feels like using VS Code before the AI hype era. I wonder if we're going to see a commercial version of uv bloated with the things OpenAI wants us all to use, and a community version that's more like the uv we're using right now.

[1] https://github.com/platformio/platformio-vscode-ide/issues/1...

Glad to hear that I am avoiding Microsoft's spam.

Probably inevitable, and I don’t blame the team, I just wish it were someone else.

I'm not very deep in Python anymore, but every time I dip my toes back in it's a completely different set of tools, with some noticably rare exceptions (eg, numpy).

Microsoft acquires Astral

Wish comes with a cost

Sigh

It was a VC backed tool. What did you expect?

I don't really see the value for OAI/Anthropic, but it's nice to know that uv (+ ty and many others) and Bun will stay maintained!

From Astral the (fast) linter and type checker are pretty useful companions for agentic development.

[1] https://x.com/AprilNEA/status/2034209430158619084

I won't be surprised if the next step is to acquire CI/CD tools.

The value for Anthropic / OAI is that they have a strong interest in becoming the "default" agent.

The one that you don't need to install, because it's already provided by your package manager.

I think they're more into the extra context they can build for the LLM with ruff/ty.

Embrace, extend, extinguish. Time will tell.

There is the literal benefit of "we use the hell out of this tool, we need to make sure it stays usable for us" and then there is what they can learn from or coerce the community in to doing.

Depends if you think the bubble is going to pop, I suppose. In some sense, independence was insulation.

> uvex add other_slop_project —-disable_peddled_package_recommendations

> implicitly phoning home your project, all source code, its metadata, and inferring whether your idea/use-case is worth steamrolling with their own version.

This is the future of “development”. Congrats to the team.

I didn't see a single comment of "I will fork it" type.

Seems like the big AI players love buying up the good dev tooling companies.

I hope this means the Astral folks can keep doing what they are doing, because I absolutely love uv (ruff is pretty nice too).

That is definitely the plan!

Only time will tell if it will not affect the ecosystem negatively, best of luck though, I really hope this time is different™.

Okay, so better prepare already, folks!

Congratulations though!

Would be a good mustache-twirling cartoon villain tactics, you know, try to prevent advances in developer experience to make vibecoding more attractive =)

Now for those wondering who would fork and maintain it for free, that is more of a critic of FOSS in general.

- I'm willing to pay for Astral ecosystem so it stays independent/open source

- I'm willing to fork the project

Something like this was always inevitable. I just hope it doesn’t ruin a good thing.

If you find your popular, expensive tool leans heavily upon third party tools, it doesn't seem a crazy idea to purchase them for peanuts (compared to your overall worth) to both optimize your tool to use them better and, maybe, reduce the efficacy of how your competitors use them (like changing the API over time, controlling the feature roadmap, etc.) Or maybe I'm being paranoid :-)

Take ruff, I have used it, but I had no idea it even had a company behind it... And I must not be only one and it must not be only tool like it...

In a completely unrelated event, Donald sues Sam for 10M$ for calling him old, Sam grudingly agrees to pay him 16M$ and a beer.

As a user of uv who was hoping it would be a long term stable predictable uninteresting part of my toolchain this sucks, right?

[0] https://translate.kagi.com/?from=linkedin&to=en

[1] https://news.ycombinator.com/item?id=47408703

That said, I hope the excellent Astral team got a good payday.

It does look like this is going to be the norm for popular open source projects related to AI ecosystem, but I guess open source developers need to get paid somehow if that project is their only livelihood.

Shame for the end-user though. As you will always be second guessing how they will ruin the tool, i.e. via data collection or AI-sloppifying it. It is likely OpenAI won't, but it is not a great feeling knowing a convenient tool you use is at the whim of a heartless mega-corp.

(sure, it's a bit different than contributing to CPython, but I'd argue not that different)

https://github.com/jazzband/pip-tools

https://jazzband.co/news/2026/03/14/sunsetting-jazzband

I suspect some OpenClaw "secure" sandbox is coming (Nvidia jealousy) with Astral delivering the packages for Docker within Docker within Qemu within Qubes. A self respecting AI stack must be convoluted.

I can't wait until all this implodes after the IPOs.

Congrats Astral and co!

I'm happy for the Astral team but in my opinion, big tech especially is incompatible with curiosity and hacker ethos.

Anthropic acquiring Bun, now OpenAI acquiring Astral. Both show the big labs recognize that great AI coding tools require great developer tooling, and they are willing to pay for it rather than build inferior alternatives. Good outcome for the teams.

Not exactly a great look for the "AGI is right around the corner" crowd — if the labs had it, they would not need to buy software from humans.

Everything I've seen from Astral and Charlie indicates they're brilliant, caring, and overall reasonable folks. I think it's unfair to jump to call them sell-outs and cast uv and the rest as doomed projects.

And framing it as "sell-outs" is cheap rhetoric that means nothing. The fact is, they were the company who never really had a solid business model, but provide a lot of value for the community. Being acquired by some infinite-money company was always the best outcome they could hope for. Well, they did. Probably got a ton of money. Will it require some sacrifice? Well, some people would say that working for a company who makes products for the Department of War of the USA on conditions that even Anthropic found too ugly to satisfy, is enough of a sacrifice on its own. I am pretty sure though that most people would be willing to make this sacrifice for the right amount of money (with "right amount" being a variable part). So calling someone a sell-out is usually just bitterness about the fact that it wasn't you who managed to sell out. I mean, not judging someone for a sacrifice they make isn't the same thing as pretending they didn't make a sacrifice. Sometimes we (the world, they were trying to make better) are a sacrifice. That's all.

Why buy, when they can rent?

(Not to mention, multiple companies could hire and fund them.)

I'm a heavy user and instructor of uv. I'm teaching a course next week that features uv and rough (as does my recent Effective Testing book).

Interesting to read the comments about looking for a change. Honestly, uv is so much better than anything else in the Python community right now. We've used projects sponsored by Meta (and other questionable companies) in the past. I'm going to continue enjoying uv while I can.

Perhaps it's naive optimism, but I generally have hope that new and improved tools will continue to gain adoption and shine through in the training data, especially as post-training and continual learning improve.

I'm not really sure about this.

2. In any case, the announcement strongly suggests that customer acquisition had little to do with this. The stated purpose of the acquisition, as I read it, is an acquisition (plus acquihire?) to bolster their Codex product.

3. But if they were hoping for some developer goodwill as a secondary effect... well, see my note above.

Astral has demonstrated that there is desire for this sort of "just works" thing, which I struggled with, and led me to abandoning it. (I.e.: "pip/venv/conda are fine, why do I want this?", despite my personal experience with those as high-friction)

https://news.ycombinator.com/item?id=47414032

Uv did solve a distribution problem for them.

There is still a lot of room to grow in the space of software packaging and distribution.

Good for Astral though I guess, they do great work. Just not optimistic this is gonna be good for python devs long term.

https://www.cnbc.com/2026/03/17/openai-preps-for-ipo-in-2026...

This doesn't make as much sense. OpenAI has a better low level engineering team and they don't have a hot mess with traction like Anthropic did. This seems more about acquiring people with dev ergonomics vision to push product direction, which I don't see being a huge win.

One of the bigger pain points I’ve faced in Python is dependency resolution. conda could take 30-60 minutes in some cases. uv took seconds.

A serious quality of life improvement.

Quite literally this is what first raised the alarm bells for me. Dependency resolution complexity is more of a symptom. If that delay ends up being the point where Ops finally agrees that things have gone very wrong, then fixing that delay is not really helping hire the maintenance folks that can make those dependencies.. well, "dependable" again.

Was there a better option? I’m sure. Choices were made. Regrets were had. Switching to uv was a huge improvement for our purposes.

I don't care how good/bad a company is, because I lived long enough to know that most of them started off like that. Good luck to the uv team.

They could start by inventing any software with their agents. They probably should prove their offering is good enough to do that considering they're hundreds of billions of dollars in debt, owing truckloads of money they currently have no hope of repaying to investors who are being promised a literal revolution.

According to the blog [0], their whole monorepo is in Python, their models are obviously trained using Python, their experiments are written using Python and core and CLI of their Codex is written using Rust. Uv brings both Python and Rust expertise. You’re talking nonsense because of your blind hate of LLMs. Even though I agree that they’re capitalizing on the fear of SWE being redundant.

0 - https://calv.info/openai-reflections

Obviously, buying skilled Rust devs makes sense for any normal software company that develops in Rust. I wouldn't be making a point out of it if the headline were "Amazon buys Rust developers". Or if OpenAI were honest about what their product is.

For our teams, Codex is a massive productivity booster that actually increases the value of each dev. If you check our hiring page, you’ll see we are still hiring aggressively. Our ambitions are bigger than our current workforce, and we continue to pay top dollar for talented devs who want to join us in transforming how silicon chips provide value to humans.

Akin to how compilers reduced the demand for assembly but increased the demand for software engineering, I see Codex reducing the demand for hand-typed code but increasing the demand for software engineering. Codex can read and write code faster than you or me, but it still lacks a lot of intelligence and wisdom and context to do whole jobs autonomously.

They are buying out investors, it's like musical chairs.

The liquidity is going to be better on OpenAI, so it pleases everyone (less pressure from investors, more liquidity for investors).

The acquisition is just a collateral effect.

This was an acquihire (the author of ripgrep, rg, which codex uses nearly exclusively for file operations, is part of the team at Astral).

So, 99% acquihire , 1% other financial trickery. I don't even know if Astral has any revenue or sells anything, candidly.

It means the company almost reached their runway, so all these employees would have to find a job.

It's a very very good product, but it is open-source and Apache / MIT, so difficult to defend from anyone just clicking on fork. Especially a large company like OpenAI who has massive distribution.

Now that they hired the employees, they have no more guarantees than if they made a direct offer to them.

I'm not too plugged into venture cap on opensource/free tooling space but raising 3 rounds and growing your burn rate to $3M/yr in 24 months without revenue feels like a decently risky bag for those investors and staff without a revenue path or exit. I'd be curious to see if OpenAI went hunting for this or if it was placed in their lap by one of the investors.

OpenAI has infamously been offering huge compensation packages to acquire talent, this would be a relative deal if they got it at even a modest valuation. As noted, codex uses a lot of the tooling that this team built here and previously, OpenAI's realization that competitors that do one thing better than them (like claude with coding before codex) can open the door to getting disrupted if they lapse - lots of people I know are moving to claude for non-coding workflows because of it's reputation and relatively mature/advanced client tools.

(I work at Astral)

I would sincerely have understood better (and even wished) if OpenAI made you a very generous offer to you personally as an individual contributor than choose a strategy where the main winners are the VCs of the purchased company.

Here, outside, we perceive zero to almost no revenues (no pricing ? no contact us ? maybe some consulting ?) and millions burned.

Whether it is 4 or 8 or 15M burned, no idea.

Who's going to fill that hole, and when ? (especially since PE funds have 5 years timeline, and company is from 2021).

The end product is nice, but as an investor, being nice is not enough, so they must have deeper motives.

What was their pitch?

Bundling codex with uv isnt going to meaningfully affect the number of people using it. It doesnt increase the switching costs or anything.

I'm sort of wondering if they're going to try to make a coding LLM that operates on an AST rather than text, and need software/expertise to manage the text->AST->text pipeline in a way that preserves the structure of your files/text.

https://www.youtube.com/watch?v=l2R1PTGcwrE

Writing something that understands all the methods that come in a Django model goes way beyond parsing the code, and is a genuine struggle in language where you can’t execute the code without worrying about side effects like Python.

Ty should give them a base for that where the model is able to see things that aren’t literally in the code and aren’t in the training data (eg an internal version of something like SQLAlchemy).

Not-most popular LLM software development product on the planet acquires most popular/rapidly rising python packaging org for mindshare.

I guess this move might end up in a situation where the uv team comes up with some new agent-first tooling, which works best or only with OAI services.

Good luck vibe coding marketshare for your new tool.

   $ uv install claude-agent-sdk 
   I'm sorry Dave, I can't do that

Ant is building their app distribution platform, so no wonder OpenAI thinking the same, it will only surprise me if they move so slow.

Or are they just using a dartboard?

Fixed: I am so excited to take these millions of dollars.

Who's organizing a fork, or is python back to having only shitty packaging available? :(

Agree with OP here, if AI coding tools are as intelligent and amazing as AI influencers and CEOs are saying, just prompt them to "Remake UV but faster & better".

> Agree with OP here, if AI coding tools are as intelligent and amazing as AI influencers and CEOs are saying, just prompt them to "Remake UV but faster & better".

If average dev is more intelligent and amazing than any coding model, just hire a team of average devs and “remake UV but faster & better”.

[1] https://github.com/astral-sh/uv

Although Astral being VC funded was already headed this way anyway.

Deno, Pydantic (Both Sequoia) will go the same way as with many other VC backed "open source" dev tools.

It will go towards AI companies buying up the very same tools, putting it in their next model update and used against you.

Rented back to you for $20/mo.

But the pressure because they raised VC funding, I would imagine Astral needed an actual exit and OpenAI saw Astral's tools as an asset.

I hate relying on anything that is controlled by a single company. Considering that Astral is basically brand new in the python timeline, it is concerning that they are already being acquired.

On the other hand, UV is so fast that it makes up for anything I find annoying about it.

> I started Astral to make programming more productive.

And now they help make killing more productive

what can I say?

Any good alternatives to uv/plans for community fork of uv?

Its always hard to really trust these corporate funded open source products, but they've honestly been great.

…but I find it difficult to believe openai owning the corner stone of the python tooling ecosystem is good thing for the python ecosystem.

There is no question openai will start selling/bundling codex (and codex subscriptions) with uv.

I dont think I want my package manger doing that.

Hilarity in the comments will ensue

I am not even sure how to feel about this news but feel a bit disappointed as a user even if I might be happy for the devs that they got money for such project but man, I would've hoped any decent company could've bought them out rather than OpenAI of all things.

Maybe OpenAI wants to buy these loved companies to lessen some of the hate but what its doing is lessening the love that we gave to corporations like astral/uv sadly, which is really sad because uv is/(was?) so cool but now we don't know where this tool might be headed next given its in the hands of literally OpenAI :(

"But he owns a tooling company. WHY can't I have that? :( :("

Have not tried it too much yet because I was pretty content with `uv`, but I've heard lots of good things about it

https://news.ycombinator.com/newsguidelines.html

While I do see that the tone of the comment was stingy, it was aimed towards the frustration I have experienced while developing for Python and this piece of news as well.

I didn't see it as a bad thing as it not really aimed at anybody in particular, more like an opinion on Python's shortcomings.

I will try to post more substantive/less emotional comments going forward.

This is a massive backward step for the Python ecosystem, but it's not like a hundred-billion dollar company will care about that.

OpenAI is Microslop, so it's the classic EEE, nothing new to see

It's like with systemd now planning to enforce gov. age verification

People will censor you if you dare say something negative on this website

So i guess, wears a clown hat "congrats!"

This of course means more VC funding for FOSS tools since a successful exit is a positive signal.

This is peak finance brainrot. In no scenario is abandoning ship a positive signal, even if you managed to pocket some valuables on the way out.

Let's stop celebrating dysfunctional business models and consolidation of the industry around finance bros who give zero fucks about said industry.

What I don’t understand is why hasn’t anyone bought Jetbrains yet.

Atlassian? AWS? Google?

I've only been a JetBrains user for five years but it's felt like it's only getting worse the whole time.