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.
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.
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)
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.
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).
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.
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.
For me it is not only about censorship resistance, it is also about having everything stored in git (so you loose nothing if you decide to move around) and about easy way to be a node itself (you installed Radicle? Congrats, you're a node in the network - you participate, you help, you extend. You can make a permanent node with domain name but you're already a node once you installed Radicle and started the node daemon).
It is this radical idea that everyone can easily be an equal participant in the network and that they have power over what they want and don't want. Open source nature further helps you to adapt things - don't like our web UI local-first interface? Build your own one or adapt ours to your need.
Here you go [0] - the project hasn't launched yet and there are bits and pieces to be dealt with, the current focus is a bit somewhere else. You can also build from source [1] with Rust's cargo.
Thanks but... no thanks, you've missed my point entirely. Why would I want to run peer to peer software built by developers whose security stance starts with curl-bash? Would you curl-bash a webserver? an email server? No? Probably even worse for your source code repository then right?
The problems with curl-bash are overblown. You are pretty much exactly as vulnerable running pip install, npm install, or cargo install.
Not that curl bash is great, but it's not uniquely horrible when the goal is to run some unvetted code on your machine.
If you care about security, you have to either vet the code or trust the source. When you install through your package manager, you're trusting the maintainers. When you install from curl bash, a random website, or any unvetted software source, you are electing to trust the developers or site directly.
The big difference with curl|bash is that the download itself gets to execute in the context of the computer as it is downloading, which is a super power that makes it much easier to hide behaviors as you can make it extremely difficult for people to ever be able to just download a dead copy of the script to analyze it for malware.
The counterpoint would be: you're intending to run their code, if it's malicious then you're hosed anyway.
In bygone times, one might suffer from a truncation attack or otherwise end up running arbitrary code that's not what the vendor intended. Nowadays, there's really no security difference in curl|bash vs downloading a package and running it. Or, indeed, installing using `cargo install`.
That doesn't mean I'm happy running it, but my argument against it is less a security argument and more a predictability one: I want to be able to cleanly uninstall later, and package managers normally provide more consistent support for uninstalling than an arbitrary shell script.
The cleanup and uninstall concern is one of the reasons I run as many things in containers as I can. It's so easy to blow away a container and its volumes compared to traditional software uninstallation.
I realize I'm just some rando on the Internet, but I'm begging you please don't introduce Yet Another CI Job Specification ™
I'm sure you have your favorites, or maybe you hate them all equally and can just have a dartboard but (leaving aside the obvious xkcd joke) unless you're going to then publish a JSON Schema and/or VSCode and/or IJ plugin to edit whatever mysterious new thing you devise, it's going to be yet another thing where learning it only helps the learner with the Radicle ecosystem, and cannot leverage the existing knowledge
It doesn't even have to be yaml or json; there are quite a few projects which take the old(?) Jenkinsfile approach of having an actual programming language, some of them are even statically typed
I also do recognize the risk to your project of trying to fold in "someone else's" specification, but surely your innovation tokens are better spent on marketing and scm innovations, and not "how hard can it be" to cook a fresh CI job spec
I likely would have already written a much shorter comment to this effect, but having spent the past day slamming my face against the tire fire of AWS CodeBuild, the pain is very fresh from having to endure them thinking they're some awesome jokers who are going to revolutionize the CI space
Appreciate both the clear feeling and nuanced take here!
It’s interesting, because it’s like the problem is partly that most of the CI offerings out there are at least a little bit gross, but also the vast number of mediocre CI offerings is a factor too.
It feels like it’d be easy to convince yourself that what you’ve built is better than everything that exists already, and hey, maybe it is! But personally I wonder if we really need is a step-change here, not an incremental improvement—something that really does make build and deploy easier, and changes how we all think about it too.
My life experience has been that answering the question is almost always a matter of "easier ... for whom ... to do what?" I think CI/CD systems often run up against the same problem that programming language adoption runs into: trying to be all things to all people for all problem domains is incredibly hard
Even what I mentioned about static typing I'm sure caused a blood-pressure spike in some readers, since some folks value the type safety and others consider it "line noise". Some people enjoy the double-quote free experience of yaml, others pound on their desk about the 7 ways to encode scalars and "but muh norway!!11"
But, taking our ragingly dumbass buildspec friend <https://docs.aws.amazon.com/codebuild/latest/userguide/build...> as a concrete example, how in the holy hell did they invent some build language without conditionals?! I'm sure the answer is "well, for our Amazon-centric use case, you're holding it wrong" but for someone coming from GitLab CI and GitHub Actions which both have "skip this job if today is Tuesday" it's a pretty glaring oversight
Hey, we are having fun doing it :) It is already pretty nice for testing things and show us the results. It is not going to be forced on users at all and it will share parts of the code with all the third-party CI integrations that we are working on.
so it's the same as cloning a repo locally, auto updating it, and exposing a mirror to the world?
how will this not devolve into freeNet fiasco when popular repos start to go wild on content?
edit: i see from the finance thread you will likely take on maven/npm/etc with crowd hosting+funding so I'm now more curious how cheap it will be for bad actors to push intentional malicious content, since now it's mostly about cost of having consensus over the mirrors
Pine is not overpromising things and is doing more organic growth which will sustain. That said, I can confirm that I saw Ubuntu Touch running on PinePhone.
I think that is fair to say but I was pretty mad at pine years ago when I bought their first product. There was definitely plenty of hype. They seem to have learned from that though.
I'm not doubting the things you said in the interview which certainly make it sound like a difficult place to work but it is easy to see that resentment colors your perspective. I might feel the same myself were I in your place.
Tbh, it was very easy to slip this one in if someone didn't pay attention as it was integrated with hosting provider at that time. I removed it inside something like month (aka when I got time from other more pressing deals).
That’s not the usual meaning of the term “has binary blobs”; if they’re separated in that way, it doesn’t present the usual problems which “binary blobs” usually means.
You’re arguing that fully Open Hardware is the only acceptable thing for freedom. I’m not saying that you’re wrong, but was this your opinion when your were CTO? Are the Purism laptops all Open Hardware?
I am not arguing anything, I am stating my opinion.
I spent my time in Purism cleaning such false claims about laptops and I was open about where we stand with it. That said, laptops have less issues than modern phones regarding freedom part and people just need to be aware and honest about it and not say "no binary blobs" when actually you will use binary blobs for crucial capabilities of modern phone otherwise you will have a brick in your pocket.
