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
Attachment:
pgp1NE1nfpLGQ.pgp
Description: PGP signature
_______________________________________________ advisory-board mailing list advisory-board@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/advisory-board
