[bsaul]

Is it me or does anyone else interprets all the recent wave of open sourcing as a trend to not create open standards anymore, but instead open source the technology altogether (without even creating the standard).

Have standards failed ?

[obstinate]

My 2c, not speaking as a Google rep but as myself, is that if you have a problem only a single actor needs to solve, you're going to end up with software, not a standard. To get a standard, you have to have a situation where the value of cooperation is higher than the cost.

There are plenty of people now who need to solve the container problem, but Googlers been working on this shit for years, before it was really on anyone else's horizon. Google employees incepted the cgroup feature way back in 2006, to solve problems that were already being felt acutely at that time within Google. Folks have been working on this stuff a long time before it mattered to anyone else, and that's why what's coming out is software rather than standards. There is no way a big company is going to delay solutions to an urgent strategic problem in order to be part of a democratic process for the sake of a few people's ideals. Maybe if they'd seen it coming five or ten years in advance, to give enough time for the standardization process to occur, but Google was far too small and the future far too uncertain in 2001 to predict what might be needed in 2006.

[sitkack]

Almost every problem that containers solved, was solved with EclipseBSD http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.25.8... way back in 1998

[menage]

Yes, the concept of resource control wasn't new. Getting it from a research project to the form where it was production-ready and supported for inclusion in the mainline tree of Google's kernel of choice took a bit longer.

[sitkack]

I used EclipseBSD, it was production ready. The community wasn't receptive at the time for getting it into the mainline FreeBSD tree.

For this I applaud Google for making it in, even when the masses don't see the point.

[VikingCoder]

Standards are great when multiple companies want to provide the same service, which must communicate with software written by other companies.

Compiler toolchain, devops, sysadmin, languages, runtimes, etc don't really fit that picture.

[mateuszf]

This is a very good debate regarding this very topic: https://www.youtube.com/watch?v=kRVWjC6osuw

TLDR: we are in a stage where we don't know yet what functionality needs to be supported, it is not a good time to form standards, it is a time for checking possibilities and finding best technical solutions.

[ademarre]

This is an interesting question. Really, open source and standardization are not competitors. Ideally you'd have both at once; multiple open-source implementations of a standard specification.

That said, there are times when the business model behind an open-source project is ostensibly at odds with standardization. The situation between Docker and CoreOS' app container spec comes to mind. The Docker container spec was defined by the implementation, not the other way around, and CoreOS took that opportunity to define an actual spec (and an implementation). Heated debates erupted.

In the area of cloud orchestration which Kubernetes seems to fill, I think it's still in a "discovery" stage. Early on the Kuberbetes devs said they wanted to focus first on identifying the right abstractions. I imagine standardized specs might come out of it once things stabilize.

[jsprogrammer]

Why would you want your code private?

Instead, let anyone work on it and benefit.

[mbreese]

The point of open protocols and standards isn't to keep the code private, there are plenty of open source SMTP or IMAP servers.