That's just a foot in the door.

Like sentry made a good logging library, then pivoted to an observability service.

And today I use sentry because I have a great history with their product.

It's smart and a positive way to make money.

I dig it.

PS: ruff is not replacing black (although it will probably in the end), but compete with flake8 and pylint.

Sentry had a natural path into cloud services because error monitoring has a server-side component to it.

Serious question, what is the path for a linter? Where else are people paying for linting as a service?

A lot of companies would pay actual money for some semblance of supply-chain security. Hosted, verified, certified Python dependencies. This is how Red Hat made all their money in Linux. Something like "use our vetted and secure pypi instead of the free-for-all full of typo squaters and package takeovers that the public pypi.org offers."

Starting with some nice developer tooling and going from there doesn't seem crazy at all.

> A lot of companies would pay actual money for some semblance of supply-chain security.

After the core-js debacle[0] earlier this year, it was evident that alot of companies actually do not care care about supply-chain security.

Those that do will happily roll their own hosted repositories that provide little to no guarantees.

[0] https://github.com/zloirock/core-js/blob/master/docs/2023-02...

That's Anaconda's business model.

I don't know their plan, so I can't speak for them.

What I would do is build an entire ecosystem of that quality that would include a tool to solve the Python distributions problem.

Either you help with deployment on the server, and you offer hosting.

Or you help with making an installer, and you offer nodes to build installers for multiple OS and upload to multiple app stores, manage updates, cdn, permissions...

You can even start small and just help with a service for cross-compiling C extensions and scale from that.

Or provide machine learning analysis of the quality of your code and make companies pay for it.

Or go full Continuum.

They are good enough that they can pick and choose whatever they want, really.

When you solve pain, people pay. If readthedoc managed to survive by being a static rst site, astral has a shot provided they keep the business side of things in mind as nicely as they build their user stories.

> Serious question, what is the path for a linter?

The natural end state is yet another build service.

SAST/DAST products cost truckloads of money, so that’s a possible direction. The linter is a tech demo in this case.

Some SAST products cost a truckload of money.

There's a FOSS SAST product for Python already, though, called Pysa: https://pyre-check.org/docs/pysa-basics/

Cloud linting! You send your content hash to the cloud, and it’ll tell you what errors you have.

I'm inclined to agree and when they eventually die, what happens to the tool they built?

I've been using https://rome.tools and really love the work they put into it. It's clear they had people working fulltime on it. But now, what? The code is open-source, there are people working on it, but development has mostly dropped off. I guess that's okay? It just adds a lot of doubt into the longevity of the project.

I'd be wary adding these tools into your stack because their progress relies pretty heavily on VC funding and a tight runway to profitability.

> What is the point of making every half decent Developer tool a whole startup?

I mean, paying people who work on it, for one?

I’m not against folks getting paid. My question is how does one build an entire company selling a slightly better version of a widely used open source tool? Ruff is not strong enough to build a company from.

> X is not strong enough to build a company from.

I mean, these are the famous last words of a lot of non-visionaries. I'm not saying that Ruff is some kind of unicorn, but there are a lot of cases where a seemingly small improvement on an existing technology resulted in a very successful enterprise. Docker, for example. There are others that I'm sure people will chime in with.

Maybe your answer is correct but it is not useful, at all. It does not answer the question, like, providing real solutions.

Python has become a hugely critical language for science, AI/ML, finance, etc. and the current state of tooling has lagged the language's importance. I can think of lots of ways a company that solves that problem could add adjacent products and monetize them. Enterprise support, tooling for building and deploying custom lint rules, supply-chain security, managed builds, etc.

I agree and would ask: is linting that much of a bottleneck to development?

Having an automated lint run upon opening a PR seems like a minor expense, especially when you can work on other tickets while you wait.

It's much more noticeable when running locally. Going from something like black + pylint + mypy running in a pre-commit hook to black + ruff + mypy has been wonderful for me.

It lets me actually set up another terminal session to run ruff on every file change - where pylint would take seconds, ruff is essentially instant.

Side note: I really hope mypy can get the same treatment; it runs quickly once its cache is established, but it's terribly slow running from scratch.

I'm currently speeding up Mypy + Jedi in Rust. I'm pretty far already and it's definitely a lot faster. Tests are currently running 500 times faster than Mypy.

These don't have to be run on every file in the repo, only the ones that have changed. At least not often. If it takes seconds, there is something wrong.

this is too narrowly focused on what Ruff does today and not enough on what it could do for the Python ecosystem as a whole. his focus and clear execution has built an incredible wedge and brand, and his next product will probably be well received, and the next, and the next.

the opportunity to bring speed and sanity to the whole Python Ecosystem tooling is large (if you dont feel the pain, you don't do enough python) and honestly i cant belive anyone has been (crazy enough) to try this since Anaconda.

I agree with you. On the other hand, if you build something cool you may want to make some money... The problem imo, is changing the speech in the middle of the way, aham openai

I agree, but I also don't make the decision. The free market decides whether their value proposition is enough, so the company's success is dependent on the developer demand.