"We are confident we have a very robust path to revenue."
I take it that you are not at this stage able to provide details of the nature of the path to revenue. On what kind of timescale do you envisage being able to disclose your revenue stream/subscribers/investors?
As I understand it, the main customers for this sort of thing are companies making Tivo-style products - where they want to use Linux in their product, but they want to lock it down so it can't be modified by the device owner.
This can be pretty profitable; once your customers have rolled out a fleet of hardware locked down to only run kernels you've signed.
Not if the end user is an operator of safety critical equipment, such as rail or pro audio or any of a number of industries where stability and reproducibility is essential to the product.
Ever seen a default ubuntu splash screen/wallpaper on a train, coffee machine, airport terminal kiosk, bus, or other big piece of slow moving, appliance-y thing?
That is why Ubuntu Core (and similar) exist. More secure, better update strategy, lower net cost. I don't agree with the licensing or pricing model, but there are perfectly good technical reasons to use it.
Appreciate the clarification, but this actually raises more questions than it answers.
A "robust path to revenue" plus a Linux-based OS and a strong emphasis on EU / German positioning immediately triggers some concern. We've seen this pattern before: wrap a commercially motivated control layer in the language of sovereignty, security, or European tech independence, and hope that policymakers, enterprises, and users don't look too closely at the tradeoffs.
Europe absolutely needs stronger participation in foundational tech, but that shouldn't mean recreating the same centralized trust and control models that already failed elsewhere, just with an EU flag on top. 'European sovereignty' is not inherently better if it still results in third-party gatekeepers deciding what hardware, kernels, or systems are "trusted."
Given Europe's history with regulation-heavy, vendor-driven solutions, it's fair to ask:
Who ultimately controls the trust roots?
Who decides policy when commercial or political pressure appears?
What happens when user interests diverge from business or state interests?
Linux succeeded precisely because it avoided these dynamics. Attestation mechanisms that are tightly coupled to revenue models and geopolitical branding risk undermining that success, regardless of whether the company is based in Silicon Valley or Berlin.
Hopefully this is genuinely about user-verifiable security and not another marketing-driven attempt to position control as sovereignty. Healthy skepticism seems warranted until the governance and trust model are made very explicit.
As per the announcement, we’ll be building this over the next months and sharing more information as this rolls out. Much of the fundamentals can be extracted from Lennart’s posts and the talks from All Systems Go! over the last years.
I’ve now had 2 IONIQ 5s stolen in Berlin, the last a couple months ago. Each seemingly using a keyless access hacking device. That’s enough for me to not see a Hyundai or Kia in my future anytime soon.
And I very much liked the IONIQ 5. But if I can’t keep one more than 2 years, what’s the point? I’ve lost all trust in those companies, upgrade or not.
We, the Headlamp project, don't make any claims about being state-of-the-art as that's hard to define. But we do think Headlamp ranks high among having the best user experience and believe the fact that we're a 100% open-source project is a huge plus compared to some other projects in the space.
I think one area that we are rather different than other projects is that Headlamp is not only focused on end-users but also for teams looking to build their own Kubernetes UX by leveraging the Headlamp plugin system. Our thinking is that this will foster broader community participation and make Headlamp the most viable project in the space.
Thanks for dropping the mic, I'll kindly pick it up.
I'm the initiator of the Flatcar Container Linux project and former CEO of Kinvolk. Thus, I'm rather knowledgeable about the project and was involved in most decisions.
The controversy you speak of is very new to me. If you could point to any references, I'd love to be aware of them.
Firstly, there was nothing "hacked" out of CoreOS. Flatcar is literally the CoreOS Container Linux repos forked and carried on as is. Once the CoreOS EOL was reached we started updating the stale packages. That's it. Any further updates are what any distro would do in the course of maintenance to remain modern and relevant.
Secondly, anything that was previously termed the "Pro" version is now just available in the standard version. So there is no difference. To my knowledge, the project doesn't even produce any Pro versions any longer and I don't think there are even any references to it in our docs. But even when we did have a Pro version, all the work we did was done in the open and was in our source repositories. We just didn't release public builds of those.
Unlike CoreOS, we also developed* and open sourced the update server. It's called Nebraska and available here under an Apache license. https://github.com/kinvolk/nebraska
If you do find anything that is not 100% open source, let me know and I'll follow up to make sure that's corrected.
I'm happy your excited about your project. But I think you'll fine it's better in the open source space to compete on merit and form relationships rather than tear down other projects and the work of the people behind the projects.
My point is that Flatcar positioning is too cryptic and ambiguous for a lot of folks. People don't really get why they should pay for it, and that's a customer reachability issue, - a marketing problem, not an engineering one.
I'm not saying that no one should use it, or it's a bad product, it's just takes too much time and effort to get into it, to understand how the pieces of the puzzle are tied together, and why. It's really great that you've picked up EOL'ed CoreOS services and developed your own. A visual component diagram, with a couple of license icons, and a simple graphical bare metal installer would've been really nice.
> you can find all licenses for each release...
Packages SBOM doesn't give a full answer regarding architecture, existing priorities (if there's any) and project structure: what had been adopted from CoreOS and why, and what had been developed from scratch, and why ?
My primary complaint regarding "Pro" feature set, and further monetization, is that literally every growing business, with a cloud hosting provider, would target those, which makes them a necessity, not an extra option to choose from.
FlatCar should've developed something innovative to differentiate the market a bit, and monetize complex enterprise deployments, instead of sabotaging onboarding for the new folks (customer reachability), with a flat fee and "unpublished builds", of a supposedly free Open Source product. At least that's the feedback I've been able to gather on my own, so far.
> We just didn't release public builds of those.
So, if I get it right, FlatCar monetization may crumble with a "Community build" that will package all the "Pro Features" and let people use 'em for free ?
Not trying to devalue anything, but "just a viable CoreOS fork" doesn't make things magically self sustainable. It's all about the extra services that you can put on top, and real engineering problems that you may solve, for those who are willing to pay.
2. Given the team, it should be quite obvious there will be a Linux-based OS involved.
Our aims are global but we certainly look forward to playing an important role in the European tech landscape.