search

windmill-labs / windmill

Open-source developer platform to power your entire infra and turn scripts into webhooks, workflows and UIs. Fastest workflow engine (13x vs Airflow). Open-source alternative to Retool and Temporal.
https://windmill.dev
Other
10.75k stars 518 forks source link

bug: SSO user limit anti-feature #2963

Closed eligrey closed 10 months ago

eligrey commented 10 months ago

Describe the bug

This project includes an easily-removable SSO user limit anti-feature. You should not include anti-features in publicly distributed open source software, lest you risk fragmenting your community once someone forks your project and removes this anti-feature.

Business model protip: Don't include an SSO SAML implementation in your open source software the first place if you want to make it a pricing point. The cat's already out of the bag, so you can't undo it now.

To reproduce

  1. Attempt to add more than 10 SSO users via SAML

Expected behavior

All users are added

Screenshots

No response

Browser information

No response

Application version

No response

Additional Context

No response

eligrey commented 10 months ago

If you're thinking about closing this issue, please reflect on this question first: How would you react to a PR that removed all of your easily-removable DRM, and have you considered what the public response to such a reaction might look like?

rubenfiszel commented 10 months ago

Hi @eligrey ,

We are obviously aware that someone could do that (and some people do). You are correct that the proper way of doing this is to remove the SSO logic from the open-source version and repo, and then merely offer it as an obfuscated plugin for community users that would like to use it. The issue is that it takes time and overall worsen the product, where we have a long list of features that our community requested that we would like to address first.

We are not a big corporation but a group of software engineers attempting to solve a very hard problem in a market saturated with proprietary players. The software we provide is used for critical jobs and become an essential tool for our customers that not just enjoy the proprietary features but a direct relationship with us where we can help them build the best internal stack under our guidance and benefit from us developing feature requests when they need. As such, our customers (and open-source users) are very happy about our service and I am proud to share that we have achieved financial break-even (and are growing at a satisfying pace).

If someone were to create such a fork, we would just let it be and then prioritize removing the SSO part. No one will want to be stuck in a fork that will eventually be stuck in the last version that contain source available SSO.

That being said, if you are in a financial situation where you cannot afford Windmill, do not want to support the project, but absolutely need the enterprise features, we can do a gesture and grant you a license key anyway.

If you could close the issue, that would be appreciated as it's not a software bug and we try to keep a proper issue hygiene to respond to user bug reports promptly..

eligrey commented 10 months ago

Thank you for the well thought-out and detailed response!

I completely empathize with you and appreciate your nuanced understanding of the issue. I would argue that removing SSO looks bad, but it's entirely within your rights to do so, and as far as I can tell you would not have any liability concerns (as long as existing paid customers are provided with an SSO module/plugin/etc).

I don't use Windmill (yet). I use a proprietary alternative at this time. I was mostly just curious about your own awareness of potential cracks in your business model and how it may affect this open source project.

I will not close this issue myself, out of my own moral concerns. You are free to do so, but I do genuinely believe that it is net-negative to remove the existing SSO implementation.

I believe you can still be profitable after unlocking your SSO implementation, though I agree that it seems likely that this would reduce your profitability overall.

Here's a good compromise: You could promise to remove SSO related DRM once you reach a certain recurring revenue goal. That way, you get to keep growing and you don't have to unlock the feature until you are more self-sustaining with enough financial inertia. I imagine the perceived goodwill would also help dissuade competitors from underselling you by forking the project.

I'm not personally invested in this project but I'm sure those who are would appreciate a gesture like that.