OCP supporters hit back over testing claims – but there's dissent in the ranks

Re: Cole is Delusional

For guest pieces, content is more important than style and form.

As for not being technical in nature, I agree (to a limited extent). That said, there's still a lot of research. We're treading ground that vendors have to walk, so how do they do it, and why? What corners do they cut? What lessons have they learned? Can OCP implement the difficult stuff and leave the easy stuff as a todo for buyers?

And if OCP doesn't move downmarket beyond Facebook-class deployments, what's the relevance? There are only a handful of Facebook-class entities that will ever exist at any one time, and I'm not remotely sure that systems integrators have the capability to take up the slack.

If they do, what's in it for them? What's the business case for them to do so? Will it help save them in the face of the public cloud, or just draw out an inevitable painful death?

At the same time, large vendors are moving towards massive "black-box" vertically integrated endgame machines. Is OCP - and for that matter systems integrators - relevant in the fact of that sort of market shift?

As developers cut their teeth on cloud tech (private, public and hybrid) first, is OCP still relevant? Will regular enterprises even be able to field sysadmin teams and developers who code to anything other than the black-box style clouds?

And these are just the questions off the top of my head.

Re: Cole is Delusional

Hi jaybeez,

Yes I was around at the start from the golden years up to the Santa Clara Open Compute summit. so 2013 officially in the project, but worked with an SI (AVNET) for another year or so. I also know Yf Juan, the ex director of ITRI you are referring to and was in Asia for long enough (about 6 months) when the chapters were being formed for Taiwan, and yes I know Paul Rad as well (UTSA).

The Centres were an answer to a problem, the problem is not the one that most people are commenting on though. First of all you will have to suspend disbelief for a second and realize that Open Source software is nothing like open source hardware, and second stay with me through a rambling explanation.

For a start (and as the main driver for the bitching point here) the licenses used to govern contributions and manufacture are taken from the open source world, where software is can be 100% open source, or if not can be compartmented up enough that a license granting use or non assert clauses does not over reach into proprietary code. E.G. Apache License (ASF). There is no corollary to that that I know of in the hardware world. So Open compute uses the OWFa license 1.0 which grants no assert rights but not transfer of ownership. E.G. "Bob" makes hardware uses OWFa 1.0 I can make the hardware exactly the same as "Bob" defined, but I am not allowed any deviation from it because I do not own the IP, but as long as i make the hardware the way "Bob" defined then he cannot bring a lawsuit against me. At least that is how I understand it to be. Apply that logic to a project say a motherboard and see who owns what. Add to that a fear (reasonable in some cases) that to publish any technical details would be to open up Pandora's box on your IP and you can see a) why OWF was adopted and b) why publishing detailed technical information on a component is scarce. Rather it is easier to publish specifications that force a particular way of doing things, generally only ONE way of doing things.

So in a way we have an openish thing with a black box core as a result. Because to get to a meaningful state where you can understand this thing you have had to sign NDA's with ODM's and other manufacturers. Remember the specification does not say HOW you do things, just what it has to be at the end.

Now jet back to the start of open compute and remember that this is a project for hypersccale deployments. ASDF has a couple of things wrong in my opinion, a) nearly all public clouds of note certainly large ones run on some sort of "bespoke" hardware. b) most users do not give a crap about that, they care about there workload running not what makes it run, as long as there is an SLA they feel fine, the same can probably be said of large big data farms as well I mean do you think AWS run around changing failed drives every second?. So having Open sourced a specification that works for hyperscale deployments where substantial amounts of money can be thrown at hardware by in house testing teams or contracted testing teams what do we do to say ODM A produces something specification equivalent to ODM B? Or that servers from ODM A work with Knox JBODS from ODM B ? We cannot open source testing for components because we most likely have an NDA against them, we cannot open source the IP, the only thing we can do is provide tools to test against the specification, or at least that is all we can do from within side Open Compute as a foundation.

Independent testing labs can/could go a lot further, but and here is the catch it still requires the IP holders consent, and then we also get into that cost exercise I described in an above post.

So considering what the use case is Hyperscale and considering the tools at our disposal to help the community we have two wildly diverging points of view.

If I then overlayed how ODM's will make the run for motherboards or backplanes, say 20,000 in a month, and you need that volume to swallow the tooling costs for the production line (including any potentially lost revenue to the ODM by holding up other production if you need it in a rush). No ODM wants to make 20,000 motherboards just for them to sit in a warehouse, you need to take delivery of the 20,000 motherboards. This tends to put the non-hyperscale guy out of the purchasing equation.

So I go back to my two diverging points of view and only one becomes relevant.

Hopefully you can see now where a) OCP is applicable, b) why the certification is what it is c) why this is not prime time for non hyperscale.

That's not an end though, because OCP is also supposed to foster innovation, and innovation can trickle down to the little person or the non-hyperscale person. I have seen precious little of that myself in the last year or so, but then I have not tried to find it either, it seems happy to just "bimble along" in that sense ASDF is right. What I can say though is that ODM's have seen a path to take more of the "value" out of the supply chain, example Quanta with QCT, and OEM's have responded with HP whiteboxes by Foxconn and Dell with DCS (although they were around before OCP). We have seen innovation from storage companies as well think closely coupled compute and storage, seagate Kinetic was back ported to Knox i think.

So all in all I have to say OCP has been somewhat successful on what IT said it was going to deliver and not what people HOPE it is going to deliver., So Cole's main points stand, although I may not agree with the method of elucidation or self flagellation around how the points were conveyed. Also I think there are things OCP could do a lot better, it could be more communicative. It could take on board the internal and external feedback better. I am sad that OCP is still at that juncture - something that I saw in 2012-13, bit it is what it is. The problems are complex (perhaps needlessly) and what I have descried above is like pealing a layer of paint, there is still more underneath that. So most of the OCP folks do what I consider and admirable effort in trying to keep all appeased, through I agree the outliers sometimes they need a taser up the backside.

As for the external testing, well the answer may well be wrapped up in the explanation above. Proof of life (if you can call this proof of life) is using the taser and seeing if the C and I chair squeaks or smokes.

Now to keep all the lawyers happy, this is my personal subjective view, treat it as a hypothetical conversation if you like.