3 ms·

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

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/ https://handbook.gitlab.com/handbook/company/stewardship/

candiddevmike 3y ago
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.
- freedomben 3y ago
  Just clarifying, your alternative to open core is open nothing? Just proprietary it up?
  - candiddevmike 3y ago
    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.
    - freedomben 3y ago
      Nice thanks, I think you make some great points.
    - mikeshi42 3y ago
      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.)
      - candiddevmike 3y ago
        > 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.
        3y ago

candiddevmike 3y ago

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.

freedomben 3y ago
Just clarifying, your alternative to open core is open nothing? Just proprietary it up?
- candiddevmike 3y ago
  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.
  - freedomben 3y ago
    Nice thanks, I think you make some great points.
  - mikeshi42 3y ago
    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.)
    - candiddevmike 3y ago
      > 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.
      - 3y ago