[Python-Dev] collections.sortedtree

[Nick Coghlan]

On 27 March 2014 19:10, Maciej Fijalkowski <fijall at gmail.com> wrote:
> On Thu, Mar 27, 2014 at 11:07 AM, Paul Moore <p.f.moore at gmail.com> wrote:
>> On 27 March 2014 08:16, Maciej Fijalkowski <fijall at gmail.com> wrote:
>>> And random pieces of C included in the standard library can be
>>> shuffled under the carpet under the disguise of upgrade or what are
>>> you suggesting?
>>
>> The sort of thing that happens is that the relevant approvers will
>> accept python-dev as a "trusted supplier" and then Python upgrades are
>> acceptable subject to review of the changes, etc. For a new module,
>> there is a whole other level of questions around how do we trust the
>> person who developed the code, do we need to do a full code review,
>> etc?
>>
>> It's a bit unfair to describe the process as "random pieces of C"
>> being "shuffled under the carpet". (Although there probably are
>> environments where that is uncomfortably close to the truth :-()
>>
>> Paul
>
> I just find "my company is stupid so let's work around it by putting
> stuff to python standard library" unacceptable argument for python-dev
> and all the python community.

Due diligence and prudent risk management are not stupid - most open
source projects and small companies just don't have the luxury of
worrying about them, as they're so far down the list of concerns that
the additional risk of using arbitrary code downloaded off the
internet doesn't even register.

As organisations get larger, they have more to lose, so they typically
start worrying about that kind of thing. Properly vetting software for
licensing and potential security issues is expensive though, so they
usually prefer to outsource that task to trusted providers (this is
one of the key concepts that gets me paid). Contractual arrangements
and brand reputations start to replace blind trust in upstream
developers.

Is this less efficient than full open collaboration? Yes, it is - the
"verify" part of "trust, but verify" comes at a real cost in time and
money. However, there are plenty of good reasons that phrase is
"trust, but verify" rather than "trust unconditionally".

You may choose not to care about those more cautious users, and that's
fine - but they're still worth taking into account when making design
decisions if you want to cross the marketing chasm from "early
adopters" to everyone else.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia