4 ms·

Even if that were the case, they clearly don't want to invest any extra time or money in refactor. So much of Kubernetes' design has been problematic, yet they

Even if that were the case, they clearly don't want to invest any extra time or money in refactor. So much of Kubernetes' design has been problematic, yet they just limp on monkey-patching and bolting on features that take years to go from idea to implementation. If you want any major changes or simplification in K8s, wait 3 years. A traditional FOSS project is not limited in this way. The developers often just start a new major version and overhaul everything. But they don't have to answer to "the business" or huge institutional users. Commercially driven open source will always be a product beholden to stakeholders, rather than technology designed to operate as well as it can.

emodendroket 5y ago
The last task I want to be doing is having to migrate my Kubernetes definition files to accommodate someone's bright new idea.
- throwaway984393 5y ago
  You already have to do that every 9 months (or is it 12 now?) as there's no "support" after that. But the point behind major versions is you don't change your definition files as long as you stay on the old major version, which is supposed to be supported for a long time.
  - odonnellryan 5y ago
    More like 24 no? 12 until it is deprecated then 12 of support.
oblio 5y ago
> A traditional FOSS project is not limited in this way. The developers often just start a new major version and overhaul everything. And regular users hate this. Jamie Zawinski describes this funnily, eloquently and also offensively: https://www.jwz.org/doc/cadt.html https://www.jwz.org/doc/cadt.html > This is, I think, the most common way for my bug reports to open source software projects to ever become closed. I report bugs; they go unread for a year, sometimes two; and then (surprise!) that module is rewritten from scratch -- and the new maintainer can't be bothered to check whether his new version has actually solved any of the known problems that existed in the previous version. But he's right, and that's why: * regular application developers who don't care about ideology * and mass market users hate desktop Linux.
- jasonjayr 5y ago
  (don't click links to jwz.org, he hates news.ycombinator.com, you have to copy/paste so the Referrer doesnt' reflect this site.)
- throwaway984393 5y ago
  Oh sure, that's 100% true. Patches often are applied by packagers when the upstream won't apply it themselves. But there's a big difference between patches for bugs and poor design limping on because we can't change it because people depend on it. Users just want stable software. Developers want software that works better and solves more problems. The compromise is for users to stick with old major versions. At some point that's no longer tenable, but at least this way the software is free. Certainly no worse than when the same thing happens but you're paying for it.

emodendroket 5y ago

The last task I want to be doing is having to migrate my Kubernetes definition files to accommodate someone's bright new idea.

throwaway984393 5y ago
You already have to do that every 9 months (or is it 12 now?) as there's no "support" after that. But the point behind major versions is you don't change your definition files as long as you stay on the old major version, which is supposed to be supported for a long time.
- odonnellryan 5y ago
  More like 24 no? 12 until it is deprecated then 12 of support.

oblio 5y ago

> A traditional FOSS project is not limited in this way. The developers often just start a new major version and overhaul everything. And regular users hate this. Jamie Zawinski describes this funnily, eloquently and also offensively: https://www.jwz.org/doc/cadt.html https://www.jwz.org/doc/cadt.html > This is, I think, the most common way for my bug reports to open source software projects to ever become closed. I report bugs; they go unread for a year, sometimes two; and then (surprise!) that module is rewritten from scratch -- and the new maintainer can't be bothered to check whether his new version has actually solved any of the known problems that existed in the previous version. But he's right, and that's why: * regular application developers who don't care about ideology * and mass market users hate desktop Linux.

jasonjayr 5y ago
(don't click links to jwz.org, he hates news.ycombinator.com, you have to copy/paste so the Referrer doesnt' reflect this site.)
throwaway984393 5y ago
Oh sure, that's 100% true. Patches often are applied by packagers when the upstream won't apply it themselves. But there's a big difference between patches for bugs and poor design limping on because we can't change it because people depend on it. Users just want stable software. Developers want software that works better and solves more problems. The compromise is for users to stick with old major versions. At some point that's no longer tenable, but at least this way the software is free. Certainly no worse than when the same thing happens but you're paying for it.