zlacker

[return to "Launch HN: SSOReady (YC W24) – Making SAML SSO painless and open source"]
1. fishto+r7[view] [source] 2024-07-30 16:52:41
>>ucario+(OP)
This looks very cool! Having implemented SAML before, it was definitely a pain and your tooling looks painless!

That said, the pricing worries me a bit. This is a tool we'd have to build on top of. Which means that if it disappears later because you went out of business (or just changed your pricing in some way that hosed us), we'd have a whole big, unexpected engineering project to rewrite our SSO.

And given that you're giving a hosted product away for free, it seems pretty likely that you will either eventually go out of business or change your pricing.

I know it sounds silly, but as someone who'll probably have to add SSO to my current project in the next 6-12 months, I'd be a lot more comfortable betting on you if you had a sustainable-sounding paid tier other than "free for now" and "idk email us." It'd certainly make it easier to pitch to the rest of my team. :)

◧◩
2. nolear+ua[view] [source] 2024-07-30 17:05:47
>>fishto+r7
I totally understand your concern. It's very valid, and we hear it a lot.

I may not successfully convince you of the commercial logic here, but we are making a calculated bet that a generous free offering serves our long-term interests.

We're betting that this product will establish our credibility with developers and result in efficient distribution in the future. It's a pretty common commercial open source playbook not to monetize in the early days.

Thankfully, some subset of venture capitalists will happily underwrite companies with popular commercial open source products.

Please bear in mind that we're an early stage company. We will build more depth into the existing product, and we'll offer new products over time. We will charge for those new features / new products. It may take years to earn meaningful revenue, let alone generate cash flow, and we're fine with that.

◧◩◪
3. jrochk+7o[view] [source] 2024-07-30 18:13:35
>>nolear+ua
> It's a pretty common commercial open source playbook not to monetize in the early days.

Right, but what has become common, if successful at cornering market share, is then changing the license to something open-source-ish and charging money for what used to be free. Sometimes a lot of money.

Many swore they'd never do it. Many probably even meant it at first.

So, it's a concern for sure.

◧◩◪◨
4. crngef+Ko[view] [source] 2024-07-30 18:17:05
>>jrochk+7o
So then fork it and continue like that. At least you have the option as opposed to some proprietary solution
◧◩◪◨⬒
5. jrochk+6v[view] [source] 2024-07-30 18:47:35
>>crngef+Ko
Sure, that's an option.

Also an option, when choosing what to use right at the startt, is being careful about using an open source solution from a for-profit startup, and evaluating all your other options, taking into account that it may not remain open source, and if it doesn't, what place it has in your business, how hard it would be to switch then, etc.

◧◩◪◨⬒⬓
6. phatsk+uO3[view] [source] 2024-08-01 01:56:07
>>jrochk+6v
Right, the overhead of setting up SAML on your own is _a lot_ and things like this usually come with a Wal-Mart’s worth of foot guns. Even so, I’d be much more keen to spend the time up front diving into it and working on an in-house solution, rather than find myself and my team up a creek with a broken auth solution and several sprints worth of work to fix it, that’s also going to push other work out because logic is critical.
[go to top]