THis is pretty dope, but I'm still struggling to see the monetization strategy for these VC backed tooling companies. There have been so many that have existed and failed, and so many new ones cropping up. Support-contracts ain't gonna get VCs happy, so where's the exponential return?

Yeah this is the same team behind Ruff. Which is great but I have trouble imagining how it works. Maybe they plan to build like a super fast private pypi or something?

🤷 https://github.com/rome/tools I can't recall if Rome was VC backed, but it was the same concept, I thought monetized.

I have trouble imagining what they could offer that I might pay for

The one I keep coming back to is acqui-hire - the companies I've seen want to try to get large adoption for tooling, is to hopefully get acquired and then the new parent company monetizes the project somehow?

Why would a VC sink money into that though? An acqui-hire is usually a last resort exit

An acqui-hire is usually a last resort exit

I've seen a ton of companies built specifically around this approach. How they convey that to their backers 🤷 Essentially, build service X, acquire as many users, pay the overhead of building that userbase and then hope someone acquires us because of our userbase. Not like one or two companies either, a ton

I don't know what you mean... 😪

😆 Didn't even occur to me 🤦‍♂️

I mean Toolchain had a plan, and it was the same model that a lot of open source companies have tried: build great open source tools and a community around them, and then offer a managed service that those tools can use. HashiCorp is the obvious example of a company that does/did that, but also several other companies operating in a very similar space like Dagger or Earthly

Astral is just rewriting the tools of the Python ecosystem in Rust

So far, and I realllly like that 🙂 I would love to be a fly on the wall of those investor meetings - I can't envision where this goes in enough of a way to entice a VC. Buf is another company that has monetized basically an open source thing (protobufs) with their cloud schema stuff. Neat idea, and if there is no insane pressure to return 10x in 5 years, I can see that being a tidy profit centre

Support contracts maybe? But that doesn't scale well enough for VCs

Exactly, support contract approaches also generally don't require 4M of capital. Still, super intrigued by this - would love to see it work out for them

I like what Astral is doing, but I can't help like it feels slightly nefarious. The community has done basically all the requirements gathering work by developing projects like this over the years, and now they're kinda swooping in with faster shinier rustier versions of the same thing, backed by VC money, and i'm guessing with some secret plan

I've had two conversations in the last 24 hours about exactly this (one with a VC friend I was advising, the other with a prospective founder)

In the future, we'll build and sell services on top of our tools — but the tools themselves will remain free and open-source.

Like is this an enforceable promise? Is it in their charter? Do the peg the definition of free and open-source? Do they plan to do data harvesting?

but I can't help like it feels slightly nefarious.

Depending on the day, I swing back and forth from this kinda vibe to "whatever, it's open source, comes with the territory". The nature of it is that, there is theoretically a need that should be served - and if they're solving the problem in a "better" way (however you choose to define that). If these tools are worse, then adoption probably won't tick up on the long term, and if the services aren't worth the money, people won't use them. Of all places, the example I use as the height of "nefarious" or "eesh, that feels slimy" is Brave and Chromium. Building a for-profit product on top of another product that is open source, but has many many millions of dollars supporting it. Like, on one hand - eesh, on the other 🤷

Yeah... I work with OpenSearch (ES fork) and OpenTofu (TF fork)

Ha! I never knew what the name was - thought it was just OpenTerraform or something

It splits the community though, it's not pretty

I think all of these tools split the community, fundamentally. Loyalists everywhere. I move to whatever seems stable-enough, and fast-enough. JS being the wild-west of this. https://dayssincelastjavascriptframework.com/ I'm a vite person today and esbuild - is it necessarily the fastest approach? No, is it absolutely fast enough while having a good enough ecosystem. Yep!

One thing that makes this particularly difficult for build systems is that, unlike other dev tool areas like feature flags or distributed tracing or whatever, for build systems the innovation and cleverness is very largely on the client, meaning you pretty much have to give it away as OSS. The server side stuff - remote caching and execution - is more or less commoditized at this point. The one thing that isn't is observability, but people aren't willing to spend huge amounts on that. It's nice-to-have, not mission critical.

Again, that's what is surprising about Astral... their innovation is in making fast versions of these clients, but they are free. I'm really trying to picture what cloud service they could offer that is related to these that isn't a commodity.

Maybe build an ecosystem around the tools - as in, build the ecosystem, and figure it out later 🤷

Obviously they will sell serialization as a service. You'll send your data to their cloud system where they will serialize the data and send it back to you 😛

😆

I hope the companies are investing in a healthy open source ecosystem. I'm really proud that Pantsbuild didn't die when Toolchain shut down. Or when Twitter dropped Pants before that

Y'all organized for that. Pants is like its own 501(c) right?

Yeah, and we made a very conscious effort at Toolchain to grow the open source community, such as mentoring folks and coming up with the Contributor program One of the main motivations was realizing we needed a diverse set of contributors to make Pantsbuild successful. If we wanted Pantsbuild to be the build system for 90% of orgs, we needed more than Toolchain employees designing it. But like Josh said, maybe that's less relevant for Astral because they already have excellent requirements

Back on topic. I was wondering if Astral would be clever enough to take the "Range Request" shortcut on

pip compile

(E.g. don't request the entire

.whl

to get the

METADATA

, instead request enough bytes to know where the

METADATA

would be, then request just those bytes). And........ https://github.com/astral-sh/uv/blob/d99c4cacdf3292f92c2ae9902cadb07bf359dc43/crates/uv-client/src/remote_metadata.rs#L51

Is there a path to using this in pants? I currently use some silly mixture of Pipenv/pants and am not clear if this will get swapped in underneath me or if I will need to adopt something else

It's certainly possible, but since pants is volunteer led, it'd take some volunteer hours to do so

I opened an issue to track this the other day: https://github.com/pex-tool/pex/issues/2371

Lol @ the mojo reference 🙂

Just from some early benchmarking on my end, it is ridiculously performant already. I've been in the process of trying to move everything from multiple poetry repos over to pants, so was relatively cheery with the pex/pip-tools lock speeds by comparison to that, but uv is just plain nuts by comparison. The lack of multi-platform is going to be a dealbreaker for a lot of people (although as someone with torch infecting my dependencies, that's far from solved anywhere), but looking at Rye it's easy to see the vision. I doubt it will be a drop in replacement for Pants any time soon (although I hope the two tools play nicely!), but I could see PDM/poetry/Hatch rapidly having little to offer over it.

You could probably help with Torch and PEX by doing the "range request" trick in PEX...

I love how much innovation has ended up happening in the python packaging space purely in response to torch doing dependencies slightly weirdly. The range request trick is a great optimisation, but not one anyone would likely have bothered with but for torch

Following John's hints on that PEX issue, apparently pip has supported range requests via

--use-feature fast-deps

since 2020: https://pip.pypa.io/en/stable/news/#id585

• Allow the new resolver to obtain dependency information through wheels lazily downloaded using HTTP range requests. To enable this feature, invoke

pip

with

--use-feature=fast-deps

. (#8588)

with https://github.com/pex-tool/pex/issues/2375 handling exposing it in PEX and thus potentially becoming something Pants could use.