>> This is also demonstrably false. Just because cluster vendor A is >> using a completely open source stack does not mean that you have any >> less risk then Cluster Vendor B with their proprietary closed source >> stack. > > Risk is a function of your control over the stack against small or large > change of business operations of one of the suppliers. If one of the > critical elements of your stack is completely closed, you have no > control over that aspect, and cannot change it out without incurring > great cost/time/effort, yes, that is, by definition, an increased risk > versus a functionally similar part (of similar operational level and > quality) which is completely open.
Its part of the risk. If you sign a contract with a cluster software vendor that they will support those features for X amount of years then you have mitigated that risk. In comparison, you have no control over the open source community. It could be that support for a critical part of your infrastructure is no longer supported because the lead dev decides he wants to spend more time licking frogs in the amazon. You are powerless to prevent this. By your criteria I could easily argue that the risk with opensource is higher then with proprietary software. case in point: We have based a reasonable chunk of our backend infrastructure on openindiana. http://lwn.net/Articles/514046/. What do we do now? > > You said my thesis is demonstrably false, and I provided the simple > argument that supports my thesis. Your argument is ... what? You disagree? Your saying that open source software is somehow less risky than proprietary software. I dont see any evidence for this. > >> I have seen Rocks clusters that are an utter bag of shieße because the >> people deploying it had no clue and also seen Clusters based on Bright >> et al that were perfectly executed. And vice versa for that matter. > > We understand that you are currently engaged in a Bright Cluster Manager > deployment. We are (see company info in .sig) , for the record, a > reseller (in the past anyway) of their tools (though we haven't sold any > for a number of reasons that I won't get into). Do you have a business > relationship with them? I see no problem advocating for them if you > disclose your interests, though Chris S/Doug E/... are the arbiters. > I dont have a business relationship with them. They just let me play with their toys. In any case, its not about Bright. Its about your original statement that open source deployments are less risky than closed source deployments. > And here I thought we were having a nice discussion, and you slip in a > little snide comment like this. Sad. It was a joke Joe! I was making a point that blind adherence to open source can be a bad thing if a better supported, closed source alternative exists. By the same stroke, Blind adherence to proprietary is also a bad idea when a plethora of truly fantastic software is out there for free! Horses for courses etc. > And for the record, our tools (Tiburon's core > functionality) is completely open. Its written in Perl, and if we were > hit by a bus in a physical or metaphorical sense, our customers could > continue to get support by paying someone to do this. At what cost? My googles of Tiburon yielded no results whatsoever. If you dropped dead tomorrow who would be there to support your stack? There is nothing on sourceforge or Github... In addition. Could we, a company of 15 people pay for the continued development and support of OpenIndina? _______________________________________________ Beowulf mailing list, Beowulf@beowulf.org sponsored by Penguin Computing To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
