Search Engine on start.fedoraproject.org

[Toshio Kuratomi]

On Sun, Jul 25, 2010 at 01:00:58AM -0400, Máirín Duffy wrote:
> Is there a reason for what I detect to be a tinge of paranoia here? There is a
> world of difference between a well-meaning FLOSS code upstream making an honest
> mistake and a provider lying about their FLOSS-ness. I hear about the former
> all the time, the latter -never-. Is it really a concern?
> 
I agree with your analysis that I've not heard of this case often or at all.
I think Jef's concerns are two-fold:

1) How do we know that the reason we haven't heard about this is because the
services are running on the providers' machines where we cannot audit them?

2) If we come to rely heavily on a third-party service and then the service
turns out to be proprietary and we cannot get them to change, we've created
a horrible situation for ourselves in infrastructure.  Your analogy below
was great: all of a sudden we're the hosts of a party where our caterer has
refused to deliver food that we can eat.  Anything we can do to triage the
situation will come with significant work on our part and at least
a temporary degradation in services for the people using our services.

> Perfection unfortunately is rare in this world and this is no less true in
> managing complex computing systems. The whole point of a policy should not be
> perfection since that'd be a lost cause and what would it gain us but
> frustration? Rather I believe the policy should be to work only with third
> parties who have a clear committment to FLOSS that is in accordance with
> Fedora's own views on free software whenever possible. To me, that would
> disqualify Google as they seem quite content to consume FLOSS in their web apps
> without providing source, no qualms about it, no attempt to even appear to be
> running FLOSS apps. (please correct me if i am wrong.)
> 
I agree with most of this.  I especially agree that there's providers out
there who are attempting to do the right thing by FLOSS and providers who
don't appear to be making any movements to make the services we would be
consuming FLOSS.  However, there does not have to be frustration involved.
For instance, if the policy said "we must run all of our services in either
Fedora or Red Hat infrastructure" that shouldn't affect anything we host
except the start.fedoraproject.org web page.

> Also re: the API stuff - if a third party we depend on goes byebye, we are
> screwed no matter what. How is having to implement our own thing to an API with
> little warning while we bleed a better situation than:
> 
> - implementing our own thing on our own time without the messy step of ever
> having to rely on any third party proprietaryness and having dependant systems
> down for unknown time periods
> 
> - working w a third party vendor who we discover doesn't have 100% FLOSS to
> correct FLOSS issues just the same as we do w pkg maintainers today? (I would
> rather 50% FLOSS than 0%! If we miss a line do we run off stage and quit since
> the show is no longer worth finishing?)
> 
> Again re:apis as consolation - If my caterer decides the morning of my banquet
> that they can't provide the food anymore, having the intended recipes in hand
> is little solace when my 200 guests start showing up hungry...
> 
I love your analogy and I'm in agreement here.  I think that API
compatibility does not give us a smoother transition so it's not something
that we should be aiming for.  A policy could either be stricter or looser
than this.

> Honestly, I'm more comfortable with Mike's gut feeling on a decision
> understanding a specific context's complexities than a blanket policy crafted
> without any possibility of accounting for the complex scenarios that await us.
>
I'd say case-by-case by the infrastructure team.  The governance model in
infrastructure pretty much equates to what you wrote in the above quote
which is nice :-)  Writing down policy, though, has the benefit of recording
the reasoning that we should be making certain decisions.  This helps us in
two ways:

1) If mmcgrath is hit by a train or discovers a need to become a full-time
pearl diver in the Mediterranean we'll have some ideas of how to make these
decisions without him.

2) When people complain that we aren't using third party service X we can
point them to the policy which should explain the reasons that running the
service would end up being more work for infrastructure.

> If a policy is needed I think it should be board signoff on infrastructure team
> calls involving third party services case-by-case.
> 
As I said to Paul, the answer here is no.  The Board has no business
deciding on the case-by-case issues that arise here, that's purely an
infrastructure call.  I can't think of a perfect analogy within the design
team but here's two imperfect analogies:

In terms of who is knowledgable to make the call, it's like having the Board
decide that the design team must use inkscape to produce all the
hackergotchis.  The knowledge of the costs and benefits of inkscape vs
other programs and the suitability to a particular task does not reside in
the Board, it resides in the design team and therefore it should be the
design team who makes that call.

Workwise, it's like having the design team decide that they want
a certain theme for all hackergotchi but having the Board review the
hackergotchi produced by the design team and send back one's that the Board
decides doesn't fit into that theme.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/advisory-board/attachments/20100725/b61ce820/attachment-0001.bin