Search Engine on

Jeff Spaleta jspaleta at
Fri Jul 23 19:40:18 UTC 2010

2010/7/23 Máirín Duffy <duffy at>:
> If I need a cake for a party, and my mom is a baker, is it really cool
> to put her work on equal footing with other bakers in the area? When,
> you know, I wouldn't be alive without her? And she'll bake my cake for
> free?

If you are putting forward a state of publicly documented requirements
that you expect vendors to meet generally...on behalf of an
organization that you would be inappropriate to
not hold your mom to the same minimum standard of performance.  Fedora
isn't your party. It's not my party. It's something bigger.  I may
trust Red Hat like a valued family member, but that means I trust them
to meet and exceed standards of performance... not lower my standards
for them.

> I think impartiality here is a myth. Red Hat is part of Fedora's family.
> I feel that if you try to encode equality between Red Hat and some
> random vendor into policy, you're going to fail so why bother?

In not asking for equality or impartiality. I'm saying that the policy
on external deps should be looked at as a minimum standard of
performance. If we can't reasonably expect Red Hat to meet that
minimum standard of performance, we certainly can't realistically
expect others to either. It would be hypocritical of us when in
reality we feel Red Hat is a leader in openness. If Red Hat can't meet
the strictures of any minimum requirements in policy we put forward
about web services.. then clearly the policy is unworkable in practise
for any other vendor on the planet.

>>  We can still have meta arguments and make judgement
>> calls about choosing particular vendors based on track record. I
>> certainly don't intend to take intrastructure's or the board's power
>> to say we trust vendor X over vendor Y because a track record of
>> performance or unquantifiable on a case by case basis.
>> But in the scope of this discussion about crafting policy we need to
>> treat all vendors..neutrally to be credible. Red Hat can't be thought
>> of as exceptional in the lens of policy on external service providers.
> Why not?
> I think any service provider that is part of Fedora's family and
> supports Fedora should be considered over other vendors. E.g., we have
> various hosting sponsors for our website that we have rotating banner
> ads for. Certainly I'd like to see us supporting those businesses over
> say Google.

In the light of the discussion at hand. Are those hosting providers
all using open stacks all the way down to bare metal?  Or are we going
to make exceptions for them as well because they are already a part of
our family of sponsors?

I'm not saying there aren't other factors involved in choosing a
vendor for services. I'm saying that not holding vendors we trust to
the publicly stated minimum standard of performance is a dubious
practise for any governance model. If anything you craft your standard
of performance such that only your trusted vendors can meet and exceed
them. Not in a way that requires you to treat your trusted vendors as
exceptions to the rule for the sole purpose of excluding vendors your
don't like.

And I'm not discounting your personal hangups with Google. What i am
saying is, don't try gerrymander our web services policy that is meant
to discriminate against Google and then explicitly have to treat other
vendors as exceptions. The rule should be a firm minimum standard for
everyone. And then you lay case-by-case judgement calls over that.

>>  If anything we have to continually hold Red Hat to a more exacting
>> standard as a hedge against bias with the knowledge and the trust that
>> Red Hat is committed to meeting the standard of performance this
>> project puts forward.
> Why?

Because its the ethical way to move forward and to encourage more
openness across the ecosystem of web services. If we can't hold Red
Hat to our minimum standards on vendor performance, then who could we
hold to our minimum standard? Because we trust Red Hat to be the
better example, we use them as the measuring stick to hold others


More information about the advisory-board mailing list