Somehow I was hoping that astral would not be as bad as people feared. Well people were right and I was wrong, I should have known when they embraced llms in their workflows. I’m very much looking forward to help fund and develop any fork of astral’s software by people with integrity and ethics.
Seeing where some comments on this are heading, I want to remind everyone of our guidelines. Everyone is expected to follow them no matter how happy or sad you are about the announcement (i.e. make sure you are respectful even if you are expressing disappointment).
I had several times wondered what Astral’s business plan was as it seemed like they were accumulating a great team but I couldn’t see what their revenue stream was to profit from that. It all makes more sense with this news.
I have no idea how Astral employees feel about this but I know some of them (in the online like here sense) and I think they are great people and I wish them all the best and I hope this works out for them.
This does make me question though the wisdom of allowing the Python ecosystem to become dependent on tools that are produced by companies that can just be bought. I don’t think of only Astral/OpenAI here but also things like GitHub which are established monopolies that provide much benefit but are also run by companies with their own corporate interests.
Astral to join OpenAI is more informative.
Astral has investors “[Thanks] to our investors, especially Casey Aylward from Accel, who led our Seed and Series A, and Jennifer Li from Andreessen Horowitz, who led our Series B.”
Regarding GitHub specifically, this was looked into before the move. It turns out, most people are completely fine with a monopoly if it gives you enough benefits. Before the move, multiple options were considered, including a hosted GitLab instance, but ultimately, GitHub was selected. Take especial note of the “Criticism” section.
(It helps in that instance that the core code and workflow is based on git, not GitHub, and so a migration to another hosting platform would be less stressful than moving from svn → hg → git → ??? would be.)
Depending on an open source tool, even one that we use via a commercial company, gives us a guaranteed last-resort fallback (fork the tool and keep going). I don’t personally use uv and am entirely happy with pip, but for those who want more Rust in their lives, it’s there, and they’re welcome to keep using and maintaining existing versions if this takeover is a step too far.
Astral have earned a lot of trust. As long as OpenAI don’t insist on integrating their equivalent of Copilot into it, this could even be good news for the future of uv.
This could become problematic for EU user for example. Astral is now connected to the US department of defense (via openAI, according to openAI).
No matter what anybody thinks about the aquisition or astral itself, it shows that just relying on third party libraries and especially for-profit third parties, is a problem.
There was a general consent that uv fixed problems in packaging so that an upstream (builtin or pypa) fix or alternativ is not needed. I even remembered that the maintainer of hatch was thinking about retiring it, because everyone is using uv anyway. I am really happy, that he did not!
As someone who really dislikes openAI and think it is as a whole problematic for everyone on this planet, this just makes me sad. I understand that people have to eat, but I also would have hoped that astral would have considered the morality (subjective I know) of it and this deal wouldnt have happened.
In the end this news should trigger a sincere and objective discussion in the packaging community and maybe python itself, as it has a lot of implications.
Before jumping to conclusions, let’s wait and see where all this is going.
Astral’s projects are open source so the worst that can happen is that they get forked, provided enough people gather around such efforts.
“Just fork it” is the knee-jerk response to corporate takeovers of open-source projects. It sometimes works out, but in this case, you need to find a group of people who are (a) passionate about Python packaging, (b) fluent in Rust, and (c) not already employed by Astral. That sounds like a very small group of people. Oh well, Rust is super fast, who cares about sustainability or maintainability, a VC-funded company will be around forever and never do anything against the users, right?
That sounds like a very small group of people.
That sounds like hundreds, if not a thousand people.
And (d) is willing to devote some number of hours per week to uv. That reduces it quite dramatically.
Thousands of us already devote days per week to far less important open source projects.
GitHub says there are 536 contributors to uv. But that also includes one-time contributors, and people whose contributions were not Rust code. If you go deeper and consider 5 commits as the bare-minimum threshold of a potential long-term contributor to a fork, there are only 57 GitHub accounts meeting that threshold. Two of them are bots, one is Claude, and nine are publicly listed as members of the Astral organization on GitHub. A (quite generous) upper bound of 45 people is quite low for a project as important and as young as uv, especially if they were to be spare-time volunteers and not paid full-time employees.
I was just checking that too but you beat me to it - well done. Great minds.
So 536, subtract 12 members of Astral, subtract 5-10 bots, plenty of potential future contributers left over.
This is all besides the point anyway, talking abut the viability of “Just fork it”. I just don’t buy the doomsday scenario yet. Firstly, if open-tofu can be made to work, and development continued, and if enough people can be found to work on pygame-ce, then I’m not worried in the slightest about uv. Secondly, if it came to it, I’m confident I myself can build it from source and use that. I personally don’t need any new features in uv, other than security fixes. I’ve been inadvertantly pinned to an old version for a few months now anyway, and rarely upgrade my main uv on my dev machine.
Okay, I will make this direct. Will YOU fork uv and maintain it? I certainly won’t, for multiple reasons (no Rust experience, very little Python packaging experience, not really got spare hours for it). Maybe there are thousands of people who MIGHT do this, but I doubt that there’s more genuinely likely maintainers than you could count on one hand.
How many projects have you contributed to just once, and of them, how many would you even remotely consider forking and maintaining? I think ChrisW’s estimate of five commits as a threshold is, if anything, quite generous to the number of potential maintainers.
“It takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!”
A few months is a relatively short time. What will you do in five years’ time?
To be clear though, I have no horse in this race. I use pip and it’s good enough for my (very simple) needs.
I have forked the repo, I’ve still got to figure out how to build uv. But like I said, discussing the viability of forking is besides the point.
I humbly suggest we give the acquisition a chance. Or at least wait and hear what OpenAI’s intentions are. Say what you like about them, and love it or loathe it, OpenAI are already in charge of another huge software development tool (albeit, closed source): ChatGPT.
As far as we know, Charlie et al, are still working on uv (as well as ruff and ty) and the self hosted package index. Most of us were mostly happy with Astral’s judgement until two days ago, many of us very much so.
I take your point though, despite the question omitting the proviso “should it be necessary to fork uv…”.
Other than Astral’s being incredibly big boots to fill (you must be truly desperate to come to me for help with uv), if I need to put serious work into a uv fork, then unfortunately it will be for entirely different purposes and priorities (i.e. to ensure the future of existing work that relies on it), than a very loosely defined “Open Source Community”, and wouldn’t be open source at all without me having a conversation first. And going back to pip and venv or something, is a simple option, especially now we have PEP751 pylock.toml files.
I have too many thoughts about the Astral acquisition to write down, but I do want to push back against this idea of “we can always fork it.”
“We can always fork it” is technically true, but if it was meaningfully true, then OpenAI would have forked uv/ruff/ty rather then shell out the money. This acquisition presents risks to free software that can’t necessarily be mitigated.