plugins, hardware, hosting, support, there's a number of ways to offer a service for an open source project. Open Core models come to mind. Another is not having enterprise SSO as part of the core. Or not having clustering. Something that would make a VP think twice about adopting your open source solution vs using you as a vendor.
I know these are examples, so I don't want to pick on you too much, but I have one nitpick: Reserving SSO for enterprise customers is awful. Please don't do it.
See https://sso.tax/ for details but I'll quote this from it "SSO is a core security requirement for any company with more than five employees"
If a company requires SSO, they'll surely have a budget for paying for the products and services they use. The majority of OSS users won't have this requirement, and likely won't have the budget to pay for commercial features. So it doesn't make sense to give away a service that has a maintenance cost to everyone, as long as it's fairly priced.
As others are pointing out, once you've grown big enough that you can't trust everyone with the keys go the kingdom: enterprise pricing is for you.
SSO Tax is a fun meme, but it misses the point: Whether it's 5 people or even 3, you've scaled your business enough to hire people who aren't in the inner circle.
That's a fair place to consider you an enterprise.
Not sure what you're talking about. It's not like without SSO everyone in the company has to all use the same password. Services allow people to have separate users with separate privileges.
It sounds like you're unaware of why SSO is considered a security feature at all them, but it's covered right on the site: https://sso.tax/
It's to allow centralized access management. Stuff like firing someone and revoking their access from one platform instantly, instead running around and changing permissions in every tool manually. Or ensuring people in department A can't be invited to some platform for people in department B in order to limit information access.
SSO tax is predicated on the idea that the moment you outgrow the informal arrangements and liberal access, you're really a business. Seems pretty fair?
> It sounds like you're unaware of why SSO is considered a security feature
Technically it's an anti feature...
The "feature" you are talking about is really identity management not sign on (which, btw, users have different identites, outside of the scope of a single company).
At its core it's just a delete function for a username. Putting that in a script with http access should be enough (and not put behind a ridiculous price tag).
Separate services otherwise are enough, no need for SSO.
> At its core it's just a delete function for a username. Putting that in a script with http access should be enough (and not put behind a ridiculous price tag).
Can you explain more about how this works for SSO?
Let's say I'm trying to launch a product (which I am), and want to have SSO as part of the package (which I do), how do I implement what you just said?
I looked into SSO services and they're bloody expensive, so if I can cheaply do it myself, I will.
The comment about being a 'toy service' is disingenuous...
The comment about customers is possibly valid, the difference entirely your use case. If you consume services as a corp, and your goal is to be able to decouple any employee quickly, then you do not need SSO, assuming each service you use allows you the option to delete by username (with proper auth, ofc).
SSO is only needed when you want to give a customer federated access (ability to assign roles without activation on their part). For an internal corp it is largely unnecessary and a convenience thing not a security one (it is much more secure to require different passwords for every service versus a global SSO credential that gets you everywhere).
If your "customers" are your own employees, then this is your decision not a use case or a business requirement.
You're barking up the wrong tree: I communicated how SSO's value prop is defined by essentially the entire SaaS industry... if you have a problem with that value prop, Okta alone is 13B worth of short potential for you once everyone realizes they could just use a script with http access.
Let me give a contrarian argument. I dont think it is awful to have sso reserved only for enterprise customers. I think enterprise customer who are going through compliance will definitely have to but into that tier therefore.
If you think you need SSO and but you do not have the budget for upgrading to their enterprise tier, may be you are not the right customer that they are targeting to sell. It is not you, it is them.
> I know these are examples, so I don't want to pick on you too much, but I have one nitpick: Reserving SSO for enterprise customers is awful. Please don't do it.
SSO is expensive, adding maybe $10/user/month if the team adds in a purchased solution (passing the cost directly onto the client).
If the customer doesn't want to pay for it because they aren't an enterprise, you can't blame the supplier for not supplying it at a lower price than $10/user/month.
I am going to the competitor. I am paying for the software, but I don’t want your “enterprise tier”, which is really designed for 1000+ employee companies.
BTW, I did just this this morning. The AE came back to offer the enterprise package for the price of the mid-tier package.
I see, I see. The world isn't fair. We have 5 employees and we want SSO but don't need SSO. So we'll go without it. It's annoying for us but it allows your business to exist because enterprise needs SSO.
Co-founder of BoxyHQ here - We've crafted an open-source enterprise SSO because we firmly believe that robust security shouldn't be a privilege limited to large organizations. Ideally, essential enterprise-level features like this should become commonplace for all.
While we acknowledge the reasons behind SSO being in the enterprise tier, we're all on a collective journey to enhance our security measures. Open Core models are indeed a good option (my preference), yet the dynamics vary across solutions and industries. It's up to each of us to explore, experiment, and discover what resonates with our market. In doing so, we can foster growth while maintaining our commitment to supporting the community in the long run.
Well stated. I was merely showing how one could implement an open core strategy. I’m a firm believer in SSO for all (and not limited to social platforms or GitHub).
