Thoughts on OpenAI acquiring Astral and uv/ruff/ty
49 points by fuzzy
49 points by fuzzy
my main concern in the “fork and exit” case is who? the psf? clicking fork is the easy part. actually picking up the mantle, finding funding, assembling a new team capable of making quality contributions to the code, is much much harder.
Right, that's very much the biggest question.
Given how load-bearing uv is becoming for businesses that run on top of Python I expect that money would become available should OpenAI break the project in some way.
Look at what happened with Elasticsearch and OpenSearch for example. Companies can pool money through a foundation if they are suitably motivated.
Have there been any high-profile cases where a community fork failed?
The ones that immediately come to mind are only the success cases: OpenOffice to LibreOffice, MySQL to MariaDB, Terraform to OpenTofu, Redis to ValKey. Which makes me feel optimistic as I list those, but I'm wondering if that's just survivorship bias.
(I think you're right though that a fork of uv would have lots of friends, i.e., money.)
ffmpeg to libav is a notable one, as well as Audacity that someone else mentioned too.
Too early to say about xlibre.
imo, libav wasn't the same kind of community fork. the existing project was still being made available to its community of users on its existing terms - it was a developer fork by people who wanted a different direction or different working environment.
https://en.wikipedia.org/wiki/List_of_formerly_open-source_or_free_software though it only shows lack of successful community forks, not failure
You say OpenOffice-LibreOffice was a success, but that implies StarOffice-OpenOffice wasn't.
In that case, it was Sun Microsystems buying a proprietary product and changed* it into an open-source project—as opposed to a community revolt leading to two competing projects.
*Approximately. They still sold/licensed StarOffice for a while. And it's still a relevant cautionary tale: Sun didn't go far enough in making it a community project, so that when they themselves were acquired, an actual community fork was necessary (and happened).
Have there been any high-profile cases where a community fork failed? …
I'm aware of one case that's fairly high profile, with perceived failure.
It'll remain nameless; here's not the place to drag it down (and I have publicly criticised the few people who have dragged it down elsewhere).
I’ve got an opinion on the utility of your comment, sans software name, but I’m going to omit it.
:-) that's a fair criticism. You may be wishing for an obtuse option in the flag menu.
My silence on the subject is, if you like, a gentle encouragement for people to be kind if they do choose to identify a recently failed (or failing) project.
Look at what happened with Elasticsearch and OpenSearch for example. Companies can pool money through a foundation if they are suitably motivated.
I wouldn't consider OpenSearch the most fitting example. Selling Elasticsearch as a service makes the clouds big money at 0 cost, and so creating a fork becomes worth it if the alternative is to pay licensing fees that weren't there before. Same thing with RedisLab's Redis vs Valkey.
In this case nobody makes money off uv and unless OpenAI decides to start charging somehow the clouds a licensing fee to use it, I doubt you'll ever see them move a tentacle.
I sort of see uv/ruff etc. as 'finished' software, even if they stopped getting commits tomorrow they'd still be useful for a long time.
I'm curious what maintenance is required / What ongoing development is needed? Are astral tools missing crucial features that people expect? Are there still massive bugs?
Or is it just concerns around security, patching vulnerabilities etc.
I think with ruff there are always more lints that could be added or refined. As well as keeping up with new Python versions and the syntax changes that come with it.
uv does feel more complete but I expect there'll be work needed to update it for new PEPs and whatnot.
yeah, I was gonna come back to say pretty much exactly this! maybe throw ty in with ruff as “at least needs to keep up with new stuff”
Maybe it’s time to fork now to hedge against this scenario. If people for while the original project is still maintained, the burden of maintaining the fork is lower and you can get accustomed to the codebase over time. Basically you just start to listen in to what’s happening with uv and maintain a mirror that could diverge from the original codebase in the future. The upside is you can set up a parallel team and community. Idk if this is realistic or worth it, it’s just an idea.
You can get the same benefits by investing in the existing uv community, thereby diversifying it.
Just from quickly skimming their CONTRIBUTING file, I didn't see any copyright assignment, so I don't think OpenAI could do a rug-pull relicensing? I'm kind of surprised.
Have they taken in a lot of outside code contributions?
I contributed a fairly large part of the fuzzing code for ruff, at least. I don't like this acquisition, mostly because I find OpenAI repulsive. But I'm happy that my code helped people using the tool (which, ironically, does not include me). Hard to reconcile these two feelings.
python foundation is probably the best. they should adopt uv and promote them to be default, not just one of the options :|
One thing that can make the 'fork path' much harder is if the acquired project starts using agentic coding heavily, as at that point the fork will have to deal with all the bajillion lines of code that have been added in the meantime.
I don't know what the disposition of the original creators of these projects is wrt agentic coding, but when you get acquired by one of the big AI companies, I doubt you get to say "no sorry I think agentic coding sucks, I'll keep working as I did before thank you very much".
Bun runs on a healthy dose of agentic coding for example.
So the fork will now not only have to find new talent, but also either keep paying the cost of moving forward with agentic coding (by buying tokens maybe from OpenAI ironically), or buckle up and start the (potentially very long) process to simplify the whole codebase.
Of course this is all under the hypothesis that the project grows significantly in terms of LOC because of how easily agentic coding can make that happen.
That's also under the hypothesis that agentic coding makes code quality worse over time. I still hold out hope that thoughtful and intentional use of agentic coding tools can help make code better.
That's also under the hypothesis that agentic coding makes code quality worse over time.
More than a judgment over the tech itself, mine is a judgment over the mindset and the cultural norms that you will have to adapt to when working at one of those AI companies.
Maybe you can make thoughtful, intentional use of agentic coding, but maybe you don't even get to do that because the company wants to show to the world the 100x output increase that their tech enables (and maybe also because if it creates a protective moat against forks, why not do that as well, no startup manager was ever fired for creating one too many moats).
I admire your optimism but, sadly, history shows that “thoughtful and intentional use” of technology isn’t one of humanity’s strengths, and the writing is clearly on the wall that this isn’t the path our society is going to follow.
In that case I'm going to hope that the market rewards those of us who learn to use this stuff as responsibly as possible - at least in the longer term.
I think it is more likely to be a combination of crisis, response and regulation that will create long term stability, but it will be a huge shock to the largely unregulated software industry.
At this stage I consider the market to be a bit of a self licking ice cream - no amount of crisis in tech seems to make a difference any more and all the players are so big and intertwingled that the market just won’t care.
I would be more hopeful if regulators weren’t entirely captured by the tech industry, but maybe a good crisis will fix that.
I think that’s probably true, but code agents can be categorized as a massive foot gun. It’s a seductive experience, taking the lazy route and prompting it to write a bunch of your code without care.
Yeah I fully agree with that. Using them to generate higher quality codetakes a great deal of discipline and we are still struggling to figure out exactly what that looks like.
Yep. I took it as far as I could using a single agent workflow. Ultimately the highest impact is local code understanding search and debugging.
I’m lazy with tests and lean on having agents write them too much at work.
I’m trying very hard to keep code agents to read only with minimal edits.
I’ve been wondering this and you’re probably the right person to ask: can these tools do refactoring that involves reducing the amount of code? Are they any good at deleting code?
Yes, they're really good at refactoring and deleting code. I use them for this all the time.
You have to start with good tests - that's why I always tell them to use red/green TDD, it makes it much more likely that the new code they add has solid test coverage.
Then I'll use prompts like:
Refactor test_app.py to reduce duplicate code
Or more specific:
Use pytest.mark.parameterize to combine those new tests into one
Or very non-specific:
Suggest potential refactorings across the project to reduce lines of code
I prefer to have the refactoring step stay under my control, so usually I'll either tell them what to refactor or have them suggest things for me to approve.
I don't know what the disposition of the original creators of these projects is wrt agentic coding
As far as I know, they used Claude Code quite a bit -- especially for things like debugging issues and developing tools (e.g. https://github.com/astral-sh/multiplay). I do think they ultimately care about code quality though and a type checker/linter isn't really a thing you can add infinite useful features to (so there's an upper limit to how much they could add post-license change).
Yes, it seems that projects that embrace agentic coding end up with far more lines of code than they would otherwise.
Agentic coding may be a force multiplier, but resulting in voluminous output. This makes it somewhat like the audio equivalent of bringing in a larger power amplifier, where often you actually want to be improving the noise floor! You can play at 10x louder volume, but how much of it is noise?
So glad to have pushed back using uv at work, because it is VC funded. On the upside this may be the start of a community maintained fork, rendering the initial argument invalid.
Currently we are using pipenv and we are happy with it. I know poetry might be better, but I never made the switch and it works out fine at the moment.
FWIW, to anyone concerned that uv/ruff/ty is going to become AI slop, Charlie Marsh said "No AI Slop on my watch" on Discord. A few more people from the Astral team replied that they share this sentiment. It still might become AI slop, obviously, but i think it's good knowing this.