Hacker News Reader

Comment by mikeshi42 | Hacker News Reader

We're more than happy to have users self-host and deploy in a way that works with their SSO provider! Whether that's via SSO on Nginx or forking and adding SSO to Passport in their fork. Depending on the provider, it's likely very straight-forward to do.

We did explicitly choose MIT for the freedom of end users to deploy and modify the code how they want - and tried to open source pretty much everything that doesn't have a hard 3rd party dependency. We do touch a bit on how we think about the open core model as well in the README, and largely align with Gitlab's stewardship model [1] when it comes to paid vs OSS. In this case, a contribution to add SAML specifically to OSS will likely not be merged. It'd also introduce complexities with maintaining that alongside our cloud version that already includes a specific implementation of SAML.

[1] https://handbook.gitlab.com/handbook/company/stewardship/

View on HN

Balancing open core needs is pretty much an impossible task IMO. You will never do enough to placate your open source users, and you will constantly be competing against yourself and spending cycles on non-value add things. Your cloud offering will be a huge time sink chasing regulatory compliance, security, and data sovereignty needs as well. It's for all these reasons that I personally think open core with a SaaS model is no longer a sustainable option.

There's nothing wrong with asking folks to pay for software instead of giving it away via FOSS, especially if you're honest about your intentions and goals. When you choose FOSS to gain traction and rug pull your users when no one converts later on, you end up reaping what you sow.

Just clarifying, your alternative to open core is open nothing? Just proprietary it up?

Alternatives depend on what the goals of the person or organization who wrote the code are. There are various FOSS and source available options that can grant some freedoms while protecting others for the creator, such as if they want to let users still contribute and view the source.

My main point was you should get these ducks in order first and be genuine with your intentions. Don't use FOSS as a growth hack, it never ends well for the creator or the user. I don't think HyperDX is genuine with their intentions, as with all open core, it's all kumbaya FOSS until you start encroaching on their enterprise feature set.

Nice thanks, I think you make some great points.

I'd genuinely would love to learn the OSS options we'd have available here, as we'd genuinely want to build a sustainable open source project and community, while preserving as many user freedoms as possible.

I think that HyperDX is a bit different from tools like Mongo, Redis or Hashicorp in that we're a vertically integrated product from SDKs/UIs to ingestion pipeline and DBs, which is opposite kind of offering from done by the above companies (which has made them more vulnerable to the kind of rug pull you mentioned)

We're trying to be permissive with freedoms granted to the user of our code, while still maintaining governance over the project to make it sustainable.

We don't want to be source-available, as that's pretty much the opposite of what we want to accomplish (and is why we consciously did not pick a license such as BSL/SSPL/etc.)

> we'd genuinely want to build a sustainable open source project and community

How do you plan on doing that while being VC-backed? Why did you choose to be VC backed in the first place? You can create a sustainable open source project and community without any VC funding.

Honest question: where do you see they are VC backed?

It's on the front page of the app, the company behind this (DeploySentinel) is YC backed: https://www.crunchbase.com/organization/deploysentinel. The original product seems like some kind of CI tool.

Interestingly, it seems like "HyperDX" might've been part of their original product offering that they decided to open source--their main website (https://www.deploysentinel.com) doesn't include any references to "HyperDX for CI" in May of 2023: https://web.archive.org/web/20230321102146/https://www.deplo.... Seems like they're pivoting to metrics? Even more of a reason to be weary about this.

Thanks! I would have expected from them a (YC YYYY) in the title then.

funnily enough i made a similar comment on an exact same "OS" product: https://news.ycombinator.com/item?id=36774611#36775934

> it's all kumbaya FOSS until you start encroaching on their enterprise feature set.

The open core model relies on a delicate balance of ensuring that the OSS product is featureful and standalone, while successfully monetizing value added features for advanced users and enterprise customers. Not many companies do this right, but there are those that understand and handle this balance well, and manage to have both a successful OSS and commercial product. Grafana comes to mind, for example.

Just because you think that SSO is a required feature that should be part of the OSS product doesn't mean that HyperDX is using OSS as a growth hack. Nor is it fair to label a young startup that for a product that just launched.

FWIW I agree with their decision to make SSO a paid feature, but we can go over any number of features, and some OSS user is guaranteed to demand a specific feature, yet will not be willing to pay for it. SSO is not special, unless it's a core feature that the product depends on, which doesn't seem to be the case here.

When done right, open core is the best model to monetize OSS projects, and we should be thankful that companies adopt it at all. I'd use an open core product before a proprietary one any day of the week.

Reply on news.ycombinator.com