Hacker News Reader

Comment by dpeckett | Hacker News Reader

I'm not sure feature withholding has traditionally worked out well in the developer space. The churn rate for tooling is so high that if Earthly were to intentionally cripple their product I'm sure the majority of developers would just move on to other inferior, but free, options (eg. taskfile). Maybe those that remain could be converted successfully but it's quite a gamble.

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.

View on HN

For the open core model to work, the OSS product should be standalone and featureful. If users feel like it's just used to advertise a commercial product, it doesn't work. And the commercial product should offer value-added services and features that are not strictly required for the base OSS product. These should be features directed towards advanced or corporate users, and preferably something that competitors lack, or don't do a good job of.

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.

> I'm not sure feature withholding has traditionally worked out well in the developer space.

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.

In this particular case, developers could also move on to a superior and completely open alternative (Nix), so making even a semi-closed alternative with much fewer people contributing etc. was already a hard sell.

Seriously, is there an email distro or something to notify Nix users when there's a new post to go troll? It's not suitable for 90%+ of users, which seems a far cry from superior.

It's just very noticeable when half of what the industry seems to spend its time on is solved problems. You and all the others have to learn why touching the hot stove is a bad idea the same way most children do. It's frustrating to observe.

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.

I’ve recently had to learn some nix to build an IHP app (Haskell framework). Most hosting providers require a dockerfile and/or image. I couldn’t get nix to build an image on time within the hosting providers’ CI. So I gave up.

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.

We get it, nix is a better mousetrap.

Why are people ignoring you though? Because if it really was the promised land we'd all be there already. Must be something important y'all are missing about the good old fashioned hot stoves.

I'm trembling at how much you're ignoring me!

> You and all the others have to learn why touching the hot stove is a bad idea the same way most children do. It's frustrating to observe.

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.

I tried to write a serious response to your comment, but as I got further into it and you got further into personal attacks and away from substance, I decided to delete it and I'm instead leaving you with this:

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.

Speaking of personal attacks, you chose only one part of my comment where I mentioned how I did some decision making, and ignored everything else.

Well, OK, now I know who is on the high horse so let's drop it here.

Shame that tech zealotry never dies.

The open source version has to be good and valuable enough for you to bring it in as a dependency in a basic setup, and then the paid versions provide support for larger scale setups where the requirements are a bit different.

There are many ways to do that, depending on what you're offering. Limits and quotas are easy enough.

Yeah, not suggesting feature withholding per se, but a differentiator on why one would buy vs run the OSS build.

What's the difference?

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.

Their reply is not SSO, it's some toy alternative they're proposing that none of your customers would accept (like saying "Dropbox is just rsync")

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

> SSO is hairy enough that you can't write it from scratch in any reasonable amount of time for what a typical SaaS needs.

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 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.

But it should be OK to reserve SSO for paying customers.

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.

You're right. I was thinking from the position of the consumer for which SSO is both convenient and a security feature.

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.

> 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.

If you have more than 5 employees, I’m sending you a sales rep to sell SSO to you.

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.

If I have to go through a sales rep to try or buy your product, I'm going with a competitor. Zero touch is a feature, upsell opportunities are cancer.

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).

I think a nice compromise is the CircleCI/Travis model of providing limited build credits/hours. If you’re a small shop or single dev, you can use the core product for free, with the hope that you’d convert to a paying user if your business grows past the free constraint.

That is why most developer products have gone back to the timesharing days.

> I'm not sure feature withholding has traditionally worked out well in the developer space.

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.

True (for web apps and multiuser applications).

Earthly is a single binary CLI on top of Docker buildkit so it's a bit trickier for them.

I’m not claiming it’s easy. Just that withholding features while still offering free tiers is a tried and tested business model that has demonstrated a lot of success for a lot of companies.

Neither GitHub nor slack are open source

Both GitHub and Slack have free tiers. Same principle, different software license.

It isn’t the same principle though. Slack and GitHub can sell data to make a profit etc but the problem with open source is people can just host it themselves meaning the creators don’t even have that option.

Plenty of organisations prefer to have managed options and thus pay for SaaS, even from open source vendors, rather than hosting their own.

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.

Reply on news.ycombinator.com