> At the same time, you can also study how Kubernetes does the job, and come up with radical superior solutions.
I feel that's a bit of a reach. A small team will magically come up with something better than hundreds/thousands of developers that thought/developed k8s?
It's nice to think anyone can do that, but I believe only another company (and probably not a small one) could try and do that. I doubt bunch of open source contributors could come close to that.
But that's a different discussion regardless if open source or closed, big companies vs small teams issue will ever exists.
What I'm saying is that the product being open source allows you to study it, let's say you want to do something as fast as Redis, you have all that previous work open.
I don't imagine a single person in a room going line by line studying it, what usually happen is that many people study particular aspects and write about it the problems they had, improvements and so on.
> I doubt bunch of open source contributors could come close to that.
Well it depends a "bunch" of open source contributors can organise themselves and grow into organizations, there are many examples.
yes, that's what happen with MongoDB and AWS, right?
The ugly thing is that they take advantage from the brand too just saying "X brand compatible" they can use the brand reputation and re-package it, I agree on that point being an issue.
Thought doesn’t scale. A solid design/architecture can only come from a handful of minds. The hundreds/thousands of developers than can provide volume of features, not necessarily quality. This is why one person (or small team) can still be disruptive.
That's a concer of mine too and that's why I'm in favor of the BDFL[1] figure.
[1]https://en.wikipedia.org/wiki/Benevolent_dictator_for_life
> * Competition is becoming more difficult. Why to try to make another deployment manager if there's Kubernetes?
At the same time, you can also study how Kubernetes does the job, and come up with radical superior solutions.