rubenfiszel

Founder of windmill.dev, the open-source alternative mentioned at the end. This market is tough, our customers are both very demanding and hard on price. We are doing very well because we kept the team very small but I cannot imagine the pressure to deliver when having raised 20x what we did.

I love what I'm doing and I feel very fortunate for the opportunity to build a startup in a domain that I cherish, devtools, and have grown to love demanding customers as people that care about our product. But if I wasn't passionate in it and its technical challenges, I think there are easier opportunities out there to make a successful startup and can easily imagine how disappointing this segment is with the track records they had as founders.

Look very similar to the script builder portion of https://github.com/windmill-labs/windmill, but not open-source, not self-hostable, without open-source integrations (https://hub.windmill.dev/) and without a workflow engine

disclaimer: I'm founder of ^

If you need a job queue on Postgres, https://windmill.dev provide an all-integrated developer platform with a Pg queue at its core that support jobs defined in python/typescript/sql

If you want the enterprise edition, then yes

We limit SSO users in the pro versions vs enterprise because the pro version is only meant for small teams.

Prices include vCPU so that it is linear to your compute cost. Windmill is also used at scale for high-throughput and heavy jobs on enormous clusters but with very few users. We approximate that the compute part of the pricing will be approximately the same as your ec2 cost for your workers.

(Founder of windmill.dev, the closest alternative to Airplane and we are OSS)

Congrats on the acquisition Airplane team. You were a strong inspiration for us, a precursor and set a high-quality bar for pro-code developer platforms. I have nothing but respect for the Airplane team and we probably wouldn't exist in our current form without your competition.

We are ready to migrate all Airplane customers and the migration would be very smooth as many of Airplane concepts map 1:1 to our own concepts. If you need urgent migration, ruben@windmill.dev

One customer, nocd, migrated hundreds of scheduled scripts and workflows in just a few weeks and with only minor changes.

Our platform being fully open-source, you will never be at the risk of us sunsetting anything since you can fully self-host it (it is not an hybrid deployment model like Airplane where the Control plane are in the cloud). We are used by thousands of businesses including a few F500 at scale and can send reference over emails.

We are a smaller team, have raised reasonably and are close to break-even. As an open-source product, I keep in mind to resist the urge of raising too aggressively so we can keep control of our destiny and never betray our open-source principles of transparency and fair pricing.

(note: we have an example repo of the folder layout one can use to be backed by git: https://github.com/windmill-labs/windmill-sync-example, it's not all that different from airplane. See our CLI guide here: https://www.windmill.dev/docs/advanced/cli)

https://windmill.dev is a self-hostable OSS alternative to pipedream

(disclaimer: I'm founder)

Fair point, TIL about another incredible capability of the BEAM. As long as you're willing to write Elixir, this is clearly a superior scheme for deferred tasks/background jobs.

One issue I see with this scheme still is that you have to be careful of what you do at initialization of the app since now all your background jobs are gonna run that. For instance, maybe your task doesn't need to be connected to the db and as per the article it will if your app does. They mention having hot-modules, but what if you want to run 1M of those jobs on 100 workers, you now have a 100 unnecessary apps. It's probably a non-issue, the number of things done at initialization could be kept minimal, and FLAME could just have some checks to skip initialization code when in a flame context.

Thanks, fixed! (and thanks)

That's great. I agree with the whole thesis.

We took an alternative approach with https://www.windmill.dev which is to consider the unit of abstraction to be at the source code level rather than the container level. We then parse the main function, and imports to extract the args and dependencies, and then run the code as is in the desired runtime (typescript, python, go, bash). Then all the secret sauce is to manage the cache efficiently so that the workers are always hot regardless of your imports

It's not as integrated in the codebase as this, but the audience is different, our users build complex workflows from scratch, cron jobs, or just one-off scripts with the auto-generated UI. Indeed the whole context in FLAME seems to be snapshotted and then rehydrated on the target VM. Another approach would be to introduce syntax to specify what is required context from what is not and only loading the minimally required. That's what we are currently exploring for integrating better Windmill with existing codebase instead of having to rely on http calls.

That's exactly what windmill.dev is (https://windmill.dev)

Ruby is next :)

We did and started with an existing standard but quickly, trying to fit to the standard was more complex than rolling our own.

Agreed we just created yet one more standard but the bit about the input transforms being full javascript expressions or the way we encoded suspend steps was impossible to retrofit.

Those licenses are not open-source and likely to be more restrictive than what we currently offer. It was important for me to be truly open-source.

If you are using windmill as a whole, you're free to use it however you please with the AGPL but for customers with doubts, we do sell an enterprise/commercial license.

Yes it goes in that direction, however note that you can already do this in a not too hard way.

Our openflow spec is both open-source and has a full openapi definition: https://github.com/windmill-labs/windmill/blob/main/openflow...

you can use that to generate client sdks in any languages and build your own dag with it. That's what one of our customer did building a reactflow to openflow library: https://github.com/Devessier/reactflow-to-windmill

It's not as good as the decorator way but we move fast and if you still have interest for it we could prioritize it (and ask for feedbacks :))

Sorry for the lack of clarity. By product we mean white-labelling windmill, not triggering a script or flow by api.

it's faster, it supports more languages (python, but also typescript, bash, go, and raw queries to different databases)

The rest will be a matter of taste

Yes, the binary can be compiled to windows and run there as a worker but it will need a connection to the main database. Not sure how currently rundeck does it ?

So bash and powershell are a bit special since they are the only one that are not implemented as using a main function and thus have no result to return.

However, we had that feedback a few time so there is a trick. If you write your result in ./result.json, we will process it as the result of your powershell script.

Curious why you wouldn't be able to do this using a bash script in windmill and ssh to your target

The api keys can be generated to be webhook specific (that's what they are by default when you generate them in the script's UX) and hence can be made public so there is no risk to expose them publicly, they are similar to a uuid of a lambda (not a key but impossible to guess).

We require api key because every request is permissioned and hence we need to know who the script is executed on behalf of. For instance, scripts can fetch secrets/variables but those calls will be permissioned with the permissions of the caller which in this case we get from the webhook specific token.

Only if you deem SSO to be of an essential nature to such products. To me it's all semantics at this point.

But it's a complex software that require software engineers with salaries and we do not want to rely on donations so we do have to give reasons for people to pay. SSO and audit logs are good ways to segment enterprises to support the project.

Happy to expand on this. Only where you would consider to be not boilerplate, aka your business logic. I hate low-code that force me to use a rigid system for the core of my tools, but I love the velocity that it brings. What if we could have high-velocity for all the boilerplate (permissioning, queuing, frontend, secret management, etc, etc) but code for the business logic. That's what windmill is. In a way, this is what serverless was meant to be, write your business logic and servers autoscale and you can hook a gazillon managed services on top.

We bring that vision in a fully open-source and consistent platform that you can host wherever you please.

You can't win every contracts but the market we're after is immense and so even a small percentage of enterprises being more daring is sufficient.

But the argument is true for any enterprise software, you cannot be small and sell to enterprise (or you must have amazing product market fit), that's where open-source comes in.

We have overlap with many existing products, but we are the only one to provide such product, with emphasis on DX and excellent performance and scalability, and to be open-source. We do currently have a few big enterprise customers and many enterprise open-source users. It's a lot easier to get approval since they get it for free and it's fully self-hostable and air-grappable. Once they have tried it on a few non-essential workflow and see the benefits, then they are more motivated to make a case internally. Wide net, some catches until it becomes ubiquitous.

I happen to be a really strong believer in open-source so it's not just an adoption strategy but I think it happens to be also fortunately the best strategy for such infra level software.

Yes absolutely, we're even faster than lambda with dedicated workers since the design is simpler, while loop jobs from the queue while still keeping all the error handling, observability, and easy deployment.

We use a mix of AGPL for 95% of the code, Apache 2.0 for specs definitions and apis, and source-available for our enterprise plugins.

You can even self-host with SSO for 7 people. The SSO is free up to 10ppl.

You will never have to pay if you do not want to.

We believe there are many reasons to start using Windmill and most of them are not worth monetizing by themselves but we strive to build a software so great that you will move more and more stuff on there and at that point, you will want our enterprise plugins.

We also mostly monetize bigger companies.

because 95% of the tables you need for this are relational (queue, completed_job, users, etc, etc) and for the few things that are unstructured, you can represent them well in PG with JSONB (which is what we do for inputs and outputs).

Apologies, the units are seconds, fixing the graph right now. You will find more ample details on the benchmarks there: https://www.windmill.dev/docs/misc/benchmarks/competitors

We made them as easy as possible to be reproduced

We added a vscode extension to build everything from code, including manipulating the yaml or UI and have them instantly impact each other: https://www.windmill.dev/blog/launch-week-1/vscode-extension

yaml is not real code and so the part that I consider to be real code is that each step is its separate file in python, typescript, that you can edit in your code editor and have your plugins working, testing frameworks. It's normal functions that you can run locally.

It would be possible for us to do like dagster/prefect/airflow which is to use a macro-processing step/decorators to build dynamically the graph which is what our yaml is in the end, a 1:1 encoding of our dag spec called openflow: https://docs.windmill.dev/docs/openflow/

We didn't do it yet because in most cases, the decorators are a lot like yaml, they are a very rigid way of declaring that some functions are nodes that you can chain in limited ways. On the other hand, not providing that mode allow us to put more efforts in the low-code graph builder for now.

But, as someone that love compilers and built a few, I'm very eager for us to provide such a mode so it's probably a few months away :)

We'd love to have your input on the DX for data/ETL once we present it Friday so feel free to join our discord or shoot me an email at ruben@windmill.dev