5 karma · joined November 24, 2021
I find it infuriating how people don't utilise any TSC based compiler plugin codegen, to automate two way sync for database entities...
Millions lines of code, for nothing.
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.
People expect FlatCar Linux to be Free.
We were facing a lot of controversy behind Flatcar already - there's no clear Licensing policy for their "Fully OpenSource" release. Kinvolk should've prepped at least a License matrix of what's been hacked out of CoreOS - what is actually behind their "Pro Features" and how exactly it is "Fully Open Source".
"Flatcar Linux Pro Features", in terms of "Linux Kernel Optimization', "GPU instances support" with "Accelerated Networking", are Not So Pro, and are something that everyone use on a daily basis.
So, just from pure Support Monetization perspective, it's impossible to use Flatcar Linux reliably for Free (mic drop).
Probably missing few core points:
1. Without good development practices due to lack of Experience or plain old Rational Thought the only possible outcome is Operational Deficiency.
Every Best Practice is context-dependent, thus having Deficient Resources makes them inapplicable in certain cases. Some teams can really suck with the same tech stack when others flourishing using it.
2. Basic organizational anti-patterns, like Mushroom Management, and broken retrospective lead to rediculous outcomes.
Even plain old Micro-services and Micro-frontends can be a basis of Stovepiping and applying Mushroom Management. Usually, again, due to Lack of Competence and Sheer Hubris.
3. “Premature Optimization” only used in context of over-engineering by those who didn’t read the book, but use Halo-effect cognitive bias to project compensated qualities onto the term itself. There are a lot of Psychological Compensational Needs under the hood.
It’s like “Why Agile has nothing to do with Discipline ?” or “Why senior developers turning the project into a sandbox due to the lack of self-fulfillment ?” or “Why most of the MVP’s lack Concise and Validated Definition of Viability ?”
Complex doesn’t mean Hard or Expensive. Simple doesn’t mean Easy or Cheap.
Too often “over-engineering” is just an organizational and psychological issue and not an Engineering one.
Stop operating on Feelings. Six Sense of the Fifth Body Anchor Point is not a reliable Key Performance Indicator.