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"
BTW, I did just this this morning. The AE came back to offer the enterprise package for the price of the mid-tier package.
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.
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?
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.
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.
SSO is hairy enough that you can't write it from scratch in any reasonable amount of time for what a typical SaaS needs.
There's OSS SSO you can host yourself that supports enterprise : https://www.keycloak.org/
If you're B2C Firebase Auth is cheap, and doesn't actually require hosting on Firebase
I expected so, looking at how much it costs to provide just SSO as a service.
Thanks for keycloak, didn't know about that.
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.
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 wasn't thinking as the service provider that needs a way to force the folks with the big bucks to pay up.
It sucks for the little companies, but it may be necessary for the service to do so.
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.
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.
It's very tricky to balance the open core model correctly, which is why not many companies get it right. You need to invest equally, if not more, in the OSS product, and make sure users are happy with it before you even mention a commercial addon. Grafana is another example of companies that understand and do this well.
It's fine to criticise Nix for its various flaws, but any suggestion of an "alternative" that has learned nothing from it is just a collective waste of time.
For any other project, I can spend half an hour max to get a decent deployable build. The trade offs is Nix doesn’t seem to work for me.
You say that while your ecosystem still can't get away from cutesy childish terms like "flakes" and "pills". Newsflash: nobody cares. I want "a package" and "a system".
I am not impressed. Before you look down on others make your own thing look uber-professional and then uproot any and all nerd-friendly marketing from it, now and forever. "It was in fact just a phase, mom" -- that's the aura that Nix should radiate before I give it a second chance.
Nix is supposed to solve a very serious problem and if it actually succeeds in that technical goal, the next step is for them to act like it. Very often you're marketing to CTOs or other tech executives -- working programmers are only one chunk of your audience. So that ecosystem has to do better -- starting with you. Your two comments here are basically a text-book argument against using Nix.
I've been a CTO and VP of Eng and I have skipped projects that can't sound professional. I know I have missed out on good stuff; I am very well aware. But we all have only 24h in a day, and only so much energy. We have to filter. One of my filters is: perceived / marketed professionalism.
(To be fair to all sides, I like the nixos.org website. I don't like practically anything else about the ecosystem though.)
> It's fine to criticise Nix for its various flaws, but any suggestion of an "alternative" that has learned nothing from it is just a collective waste of time.
Let's start with that one: nobody needed one more programming language. Nobody will "see the light" if every new technology requires one more knowledge investment. Somebody must tell you that programmers, DevOps, full-blown Ops, CTOs etc. are already overworked and already have to know and regularly catch up with way too much.
If Nix is aiming to help people work less on very annoying problems then it should, you, actually make them work less.
Nix's marketing is a complete mess. "We want you to think less about A and B so here, now learn, X, Y, Z and you should still know A and B -- but it gets better after, one day!".
Nah.
It's fine that you found technology that you love but your bias is very clearly visible and you lack the introspection skills to see that Nix is not that impressive.
Give me a `curl ... | bash` installer plus instant onboarding plus zero upkeep (an oft complaint about Nix btw) and I am sold. Anything less than that, to me you are just one more voice in a huge crowd where everyone screams "use my thing, it's amazing!".
Differentiate yourself and people will flock to you without you having to lift a finger. The fact that this hasn't happened yet is a strong hint that Nix fans are refusing to notice and take a lesson from.
You should get off your high horse. Nobody cares about you having been a "CTO" of some random venture-backed company, it doesn't give you any credentials which you can fling at people to "win" debates online. 80% of the people on this forum have some useless title like that in their CV. You being able to write lots of words about irrelevant superficial topics doesn't mean that you have anything useful to say, even if you've previously been led to believe that these are equivalent.
I don't care where you flock. I publish all my Nix related work for free, I don't have a personal stake. Your decisions are your problem.
Well, OK, now I know who is on the high horse so let's drop it here.
Shame that tech zealotry never dies.
It’s worked well for GitHub, Slack, and pretty much every service that only offer SSO behind enterprise subscriptions.
The trick is to offer enough to make people productive but not so much that there isn’t a worthwhile upgrade path.
Earthly is a single binary CLI on top of Docker buildkit so it's a bit trickier for them.
Also you’re getting too caught up in specifics and missing the broader point. You want open source examples? How about Nexus, Redhat, nginx, prettier much all of Hashicorps offerings, basically half of why AWS resell.
The real issue with commercial open source isn’t restricting access to customers, it’s restricting access to resellers. As demonstrated with the examples above.
I think it's worked out well for Sidekiq (https://sidekiq.org). I really like their model of layering valuable features between the OSS / Pro / Enterprise licenses.
The trick is you have to do that very early on. Nerfing your open source offering by making some existing features paid-only is always going to get some backlash.
A great turn around story in recent times though is probably Docker. But that required them to abandon strict open source and make controversial license/product changes.