[zlatan_todoric]

It looks quite interesting, that's said, I wish people would stop calling projects open source when they aren't and most if not all projects here in Show/Launch are open core - same with Keep. You have a proprietary license in the project, with parts of the code with an open source license.

[motakuk]

Companies adopt different strategies when building Open Core products. Some aim to keep the Open Source portion minimal, reserving the most valuable features for their paid versions. At Keep, we chose the opposite path—moving nearly everything into Open Source. Our philosophy is that most users should be able to fully benefit from the Open Source version.

While I understand (and share) the caution around licenses, I don’t think this concern applies to Keep. With 99% of our codebase under the MIT license, it’s a far cry from just having "parts of the code with an open source license."

I recommend running Keep locally and comparing the Open Source version to the playground where full version is running. You might find it challenging to spot the differences.

I also reccomend comparing Keep Open Source to BigPanda and Moogsoft. It may be surprising how much of it Keep OSS, real MIT-licensed Keep has.

[zlatan_todoric]

Sorry, maybe I sounded diminishing in my post, and I didn't want that. However, the business is still open-core, even if 99% of it is open source. That 1% can taint the project more and more in the future (and MIT obviously allows for the open-source part to go fully proprietary in the future).

1% of cyanide compared to your body weight is still lethal.

P.S. I played a bit last night and I will for sure give it a try (I'm an idealist but still pragmatic and I hope people at Keep are similar)

[motakuk]

Regarding the "1% of cyanide" comment, I’d like to share another perspective :)

Almost every tech company has private code—typically stored in private repositories. When working on Keep, we faced a decision: should we place certain code in the EE folder under a different license or keep it in a private repo, only sharing it with a small group of enterprise customers who explicitly requested it?

We chose to put that code on GitHub.

Ironically, putting more code in the GitHub repo made it appear "less open source," even though we could have simply hidden it, making the repo look like "clean OSS" as multiple companies do. For example, those who put their products without Web UI to the open source, build UI privately and serve the "full" version in the cloud.

[zlatan_todoric]

Fair arguments and criticism. That doesn't make them better at all, I think we can agree on that (and as you mentioned the Web UI situation, yeah, that makes them way worse in gran total).

I wish you all good luck, the product looks good, I hope you monetize it and I hope no big corp forks it and makes some closed source alternative (because MIT license does allow exactly that).

[dang]

Ok, I've taken "open source" out of the title now. The definitional argument here isn't really on topic.

[shahargl]

Yo! I can say that most of our users are open source users. We are community-driven, and like 95% of the features are open source. It’s true that we need something to monetize on but I really feel that we are an open source company.

[zlatan_todoric]

Kudos. I appreciate the desire to be open source and the need to monetize (and I don't have a golden solution to it, so I would probably do something similar), but I just wish that people clearly define that they are open core because there are a lot of amazing open source projects out there, and it wouldn't be fair to them to be called open source when they aren't.

[talboren]

thanks for the clarification, sorry if it sounded like we’re thinking your comment is not legitimate. It absolutely makes sense.