Congrats on the launch! I'm working on something similar, Airplane.dev, which you mentioned in your initial post.
One thing you mentioned:
> You can think of it as a superset of both Pipedream and Airplane.dev
I don't think this is true that Windmill is a strict superset of Airplane. Airplane has a lot of functionality that Windmill doesn't seem to offer (based on my reading of your docs). A few things I noticed that are unique to Airplane:
* Ability to store everything in code that you control. In Airplane, we have a CLI that lets you deploy scripts from your own machine to Airplane. You can version control the script code as well as the metadata (name, parameters, validation rules, etc). In Windmill you have to create everything in their UI as far as I can tell. Airplane's approach is more developer-friendly and also allows you to reference other code in your codebase if you want.
* Many ways to create scripts/tasks outside of just Python and Typescript. We have a direct SQL integration, REST-based tasks without writing code, Shell, Docker, etc
* Third-party integrations (Sendgrid, Slack, etc). I only saw Slack in your docs.
There are of course things that Windmill does that Airplane doesn't (for example, Windmill is open source). Just wanted to point out that while our tools have some overlap, there are also many differences that might make one or the other a better fit.
> Ability to store everything in code that you control. In Airplane, we have a CLI that lets you deploy scripts from your own machine to Airplane. You can version control the script code as well as the metadata (name, parameters, validation rules, etc). In Windmill you have to create everything in their UI as far as I can tell. Airplane's approach is more developer-friendly and also allows you to reference other code in your codebase if you want.
https://github.com/windmill-labs/windmill-gh-action-deploy lets you sync from github, including metadata that are stored in a json file alongside the code with the same name. What this integration does is basically just sending a tar of your repo to Windmill to sync it so you do not have to centralize your code on Windmill if you do not want to. We will provide the same mechanism for local filesystems and CLI or any other source control providers very soon as the approach will stay similar.
It is not a strict superset and the approach are radically different in fundamental aspects, like operating at the source code-level versus container level, but what about the features you do not provide, like a fully-featured web editor with lsp in the backend for smart assistant. The ability to convert script parameters to UI directly and so on.
> * Third-party integrations (Sendgrid, Slack, etc). I only saw Slack in your docs.
This is disingenuous, we provide integrations for anything that has OAuth https://docs.windmill.dev/docs/contributors_guide#add-an-oau... by just needing to append the oauth informations to this file: https://github.com/windmill-labs/windmill/blob/main/backend/.... We have a hub for anyone to provide the no-code module part out of it. We will do it before the community reach a critical mass. I built this in 7 months, the product just got extremely stable and feature-complete so we can now focus on adding integrations. We expect this ways to have thousands of integrations by the end of this quarter when given your current needs for custom work on each module, it will be harder for you to grow your integrations at the same rate. We have much more than just slack already and it's comparable to your current integrations.
You have an amazing product but being open-source is not our sole differentiator, we want to build an even better amazing product.
EDIT: The point holds that our docs need improvement and it's fair to assume that every integration that is not named explicitly does not exist. Our approach is very different as we believe less in custom integrations and more on relying on existing libraries in Deno and Python. In Windmill, it is sufficient to write a main function that call an existing library, and that we add the OAuth provider information to the library of integrated OAuth to have a very high quality integration experience so we did not feel the need to name all of them.
> we provide integrations for anything that has OAuth by just needing to append the oauth informations to this file
Thanks for the clarification. I do think there is a difference between a dedicated, bespoke integration to a tool as compared to your approach, and that different customers may have different needs. I previously worked on an analytics startup, and in that industry, many products took a similar approach to what you're mentioning. However, Segment's strategy was to build first-party, high-quality connectors that took into account the particular nuances of each tool, and they were massively successful as a result.
> We expect this ways to have thousands of integrations by the end of this quarter when you will only have a dozen.
Interesting, looking forward to seeing this!
> You have an amazing product but being open-source is not our sole differentiator, we want to build an even better amazing product.
I didn't mean to imply it was the only differentiator, I meant that it was an example of a differentiator - apologies if that was unclear.
One thing you mentioned:
> You can think of it as a superset of both Pipedream and Airplane.dev
I don't think this is true that Windmill is a strict superset of Airplane. Airplane has a lot of functionality that Windmill doesn't seem to offer (based on my reading of your docs). A few things I noticed that are unique to Airplane:
* Ability to store everything in code that you control. In Airplane, we have a CLI that lets you deploy scripts from your own machine to Airplane. You can version control the script code as well as the metadata (name, parameters, validation rules, etc). In Windmill you have to create everything in their UI as far as I can tell. Airplane's approach is more developer-friendly and also allows you to reference other code in your codebase if you want.
* Many ways to create scripts/tasks outside of just Python and Typescript. We have a direct SQL integration, REST-based tasks without writing code, Shell, Docker, etc
* Third-party integrations (Sendgrid, Slack, etc). I only saw Slack in your docs.
There are of course things that Windmill does that Airplane doesn't (for example, Windmill is open source). Just wanted to point out that while our tools have some overlap, there are also many differences that might make one or the other a better fit.