• Riskable
    link
    fedilink
    English
    arrow-up
    16
    ·
    2 hours ago

    So… In no time at all, they’re going to be breached. Proving them wrong.

    Will they go back to open source after that? No. Of course not. Because it was never about security to begin with. AI is just an excuse.

    It’s like saying, “anyone can scan the source for vulnerabilities! It’s so easy. Too easy! That’s why we’re not going to justdo that ourselves and instead bury our heads in the sand and pretend the availability of source code was the problem.”

  • GrumpyBike1020@monero.town
    link
    fedilink
    English
    arrow-up
    2
    ·
    37 minutes ago

    Security through obscurity never works. This is a terrible decision, i don’t know anything about this project but it seems short sighted to focus on going closed source instead of fixing security vulnerabilities.

  • Kissaki
    link
    fedilink
    English
    arrow-up
    3
    ·
    1 hour ago

    Open core, closed extensions. Not really clear how that significantly improves the situation. I doubt they’ll diverge the two code bases(?).

    The vault symbolism is pretty bad. A software product is much different to a vault, and a sister-vault-product you publish the blueprint for anyway.

    At the same time, we still care deeply about open source. That’s why we are releasing a version of our codebase to the community under the MIT license as Cal.diy.

    While our production codebase has significantly diverged, including major rewrites of core systems like authentication and data handling, we want to ensure there is still a truly open version available for developers, hobbyists, and anyone who wants to explore and experiment.

    Huh? I don’t get it. So the open product is an older, worse/different version/codebase? And they can do that without impacting their product risk because it’s different?